Indexing for Analysts: practice questions
400 questions in four levels, all on RetailMart, the practice database of this course. Write every query yourself, get it wrong, read the error, fix it. That is how it sticks.
Answers are coming soon. Post your query in the WhatsApp Community or Discord and we will check it together.
Easy 100 questions Medium 100 questions Hard 100 questions Crazy 100 questions
Core syntax, applied directly
CONCEPTUAL Q1 What is an index, and how does it speed up reads? Q2 What is the default index type in PostgreSQL (B-Tree)? Q3 Which operators can a B-Tree serve (=, <, >, BETWEEN, ORDER BY)? Q4 What is the write-time cost of having indexes? Q5 Why doesn't an index help a full-table aggregate (SUM of all rows)? Q6 Syntax: CREATE INDEX name ON schema.table (column); Q7 What does IF NOT EXISTS add to CREATE INDEX? Q8 How do you DROP an index? Q9 How do you confirm a query USES an index (EXPLAIN)? Q10 What is a primary key's relationship to an index? Q11 Does a UNIQUE constraint create an index automatically? Q12 What is selectivity, and why do indexes help selective filters most? Q13 Why is an index on a low-cardinality column (e.g. gender) often useless? Q14 What is an Index Only Scan (intuition)? Q15 How do you list existing indexes on a table (pg_indexes)? Q16 Why can't an index help WHERE LOWER(col)=... (plain column index)? Q17 What is CREATE INDEX CONCURRENTLY for (concept)? Q18 Why might the planner ignore an index you created (stats/selectivity)? Q19 What is a composite (multi-column) index (intro)? Q20 What is a partial index (intro)? Q21 Why run ANALYZE after creating an index / loading data? Q22 What does an index cost in disk space, roughly? Q23 When should you NOT add an index (write-heavy, low selectivity)? Q24 Difference between a clustered and non-clustered index (PG has no clustered by default). Q25 Name two analyst queries that clearly benefit from an index. CREATE SINGLE-COLUMN INDEXES (25) (run on RetailMart; drop afterward to keep it clean) Q26 Create a B-Tree index on sales.orders(cust_id). Q27 Create an index on sales.orders(order_date). Q28 Create an index on customers.customers(email). Q29 Create an index on products.products(brand_id). Q30 Create an index on sales.order_items(prod_id). Q31 Create an index on support.tickets(customer_id). Q32 Create an index on customers.reviews(product_id). Q33 Create an index on stores.employees(store_id). Q34 Create an index on sales.orders(store_id). Q35 Create an index on web_events.page_views(session_id). Q36 Create an index on call_center.calls(customer_id). Q37 Create an index on sales.shipments(order_id). Q38 Create an index on products.products(price). Q39 Create an index on loyalty.members(tier_id). Q40 Create an index on customers.addresses(customer_id). Q41 Create an index IF NOT EXISTS on sales.orders(order_status). Q42 Create an index on payroll.pay_slips(employee_id). Q43 Create an index on marketing.ads_spend(campaign_id). Q44 Create an index on supply_chain.inventory_snapshots(product_id). Q45 Create an index on customers.customers(registration_date). Q46 Create an index on sales.returns(order_id). Q47 Name an index explicitly (idx_orders_custid) for clarity. Q48 Create an index on stores.employees(salary). Q49 Create an index on support.tickets(agent_id). Q50 Drop one of the indexes you created (DROP INDEX). VERIFY WITH EXPLAIN Q51 EXPLAIN a WHERE cust_id=1234 before creating the index (Seq Scan). Q52 Create the index on cust_id, ANALYZE, then EXPLAIN again (Index Scan?). Q53 Verify an index on order_date is used by a range query. Q54 Verify an email-equality lookup uses the email index. Q55 Show that WHERE LOWER(email)=... does NOT use the plain email index. Q56 Verify a join on cust_id uses the index on the FK side. Q57 Verify ORDER BY order_date LIMIT 10 uses the order_date index. Q58 Show a full-table COUNT(*) ignores indexes (Seq Scan). Q59 Verify a brand_id filter uses its index. Q60 Show a low-selectivity filter (order_status='Delivered') may still Seq Scan. Q61 Verify a prod_id join in order_items uses the index. Q62 EXPLAIN ANALYZE before/after adding an index; compare actual time. Q63 Show an Index Only Scan when selecting only the indexed column. Q64 Show that SELECT * breaks the Index Only Scan. Q65 Verify a date-range BETWEEN uses the index. Q66 Show a leading-wildcard LIKE ignores the index. Q67 Show a prefix LIKE 'a%' can use the index (with appropriate opclass). Q68 Verify an index on price is used by price > 10000. Q69 Show the planner picks Seq Scan when the predicate matches most rows. Q70 Verify a customer_id filter on reviews uses the index. Q71 EXPLAIN to confirm the index name actually appears in the plan. Q72 Show BUFFERS difference before/after indexing a point lookup. Q73 Verify a store_id filter on orders uses its index. Q74 Show how ANALYZE changes the plan after bulk data (concept on RetailMart). Q75 Confirm an index is unused for a query and explain why. INVENTORY & CLEANUP Q76 List all indexes on sales.orders via pg_indexes. Q77 List all indexes in the sales schema. Q78 Count indexes per table across the database. Q79 Find the index definition (indexdef) for a given index name. Q80 List indexes on customers.customers. Q81 Identify which columns of sales.orders are indexed. Q82 Find tables in sales that have NO non-PK index. Q83 List unique indexes vs non-unique on a table. Q84 Show the size of an index (pg_relation_size) - concept. Q85 Find duplicate/overlapping index candidates (same leading column). Q86 Drop a named index you created earlier. Q87 Drop all the demo indexes you created in Section B (cleanup). Q88 Verify the table is back to only its PK/constraint indexes. Q89 List indexes on products.products and their columns. Q90 Find which index backs the primary key of sales.orders. Q91 List the largest indexes by size (concept query). Q92 Show indexes on a join-heavy table (order_items). Q93 Identify a missing FK index from pg_indexes + foreign keys. Q94 List partial indexes (those with a WHERE in indexdef). Q95 List expression indexes (indexdef contains a function). Q96 Confirm dropping an index doesn't affect query results (only speed). Q97 Re-create an index with a clear naming convention. Q98 Show pg_indexes output filtered to a single table. Q99 Inventory all indexes and flag tables with > 5 indexes. Q100 Produce a tidy index inventory report for the sales schema. Combined ideas, multi-step thinking
CONCEPTUAL Q1 Explain the leftmost-prefix rule for composite indexes. Q2 For WHERE a=? AND b=?, is (a,b) or (b,a) better? How to decide? Q3 Can (a,b) serve WHERE a=? alone? WHERE b=? alone? Q4 When does column order in a composite index matter for ORDER BY? Q5 What is a partial index and a good use-case (active/rare rows)? Q6 What is an expression index (e.g. on LOWER(email))? Q7 How does a covering index (INCLUDE) enable an Index Only Scan? Q8 Why put the equality column before the range column in a composite? Q9 When is a single composite better than two single-column indexes? Q10 When can the planner combine two single-column indexes (BitmapAnd)? Q11 Why does a partial index for WHERE status='Cancelled' stay small? Q12 What must a query's WHERE match for a partial index to be usable? Q13 Why must an expression index match the exact expression in WHERE? Q14 Trade-off: more indexes = faster reads but slower writes. Explain. Q15 What is a redundant index (prefix of another)? Q16 Why is (a) redundant if (a,b) exists for a-only lookups? Q17 When does INCLUDE help vs adding the column to the key? Q18 How does selectivity of the leading column affect a composite's usefulness? Q19 Why might a partial index need its predicate to be IMMUTABLE-ish/stable? Q20 How to index for a frequent (cust_id, order_date DESC) access pattern? Q21 Why does ORDER BY benefit from matching the index's sort order? Q22 What is index bloat and what causes it (concept)? Q23 When does CREATE INDEX CONCURRENTLY matter (no table lock)? Q24 Why ANALYZE after creating an expression index? Q25 Give a 1-line rule for "what to index" for analyst workloads. COMPOSITE INDEXES Q26 Create (cust_id, order_date) on sales.orders for per-customer time queries. Q27 Verify it serves WHERE cust_id=? AND order_date>=?. Q28 Show it serves WHERE cust_id=? alone (leftmost prefix). Q29 Show it does NOT serve WHERE order_date=? alone. Q30 Create (store_id, order_date) and verify a store-time-range query. Q31 Create (brand_id, price) on products; verify brand + price filter. Q32 Choose the better order for WHERE supplier_id=? AND price>?; justify. Q33 Create (order_id, prod_id) on order_items; verify a line lookup. Q34 Create (customer_id, review_date) on reviews; verify latest-per-customer. Q35 Create (agent_id, status) on tickets; verify agent open-ticket query. Q36 Create (cust_id, order_date DESC) to support ORDER BY DESC LIMIT. Q37 Verify the DESC composite removes a Sort node in the plan. Q38 Create (warehouse_id, product_id, snapshot_date) and verify a lookup. Q39 Show two single-col indexes combined via BitmapAnd vs one composite. Q40 Create (region_id, ...) friendly index for store filters. Q41 Create (campaign_id, spend_date) on ads_spend; verify. Q42 Create (employee_id, salary_year) on pay_slips; verify. Q43 Create (call_reason, agent_id) on calls; verify. Q44 Decide column order for WHERE order_status=? AND order_date>=?. Q45 Create a composite to support a GROUP BY cust_id, order_date::month. Q46 Verify a composite enables an Index Only Scan when selecting only its columns. Q47 Add INCLUDE(net_total) to (cust_id, order_date) for a covering scan. Q48 Show the INCLUDE version yields Index Only Scan for SELECT net_total. Q49 Identify a redundant single-column index given a composite; drop it. Q50 Drop the composite indexes you created (cleanup). PARTIAL & EXPRESSION INDEXES Q51 Create a partial index on orders(order_date) WHERE order_status='Cancelled'. Q52 Verify the partial index serves a Cancelled-orders date query. Q53 Show the partial index is NOT used for a non-Cancelled query. Q54 Create a partial index for unresolved tickets (WHERE resolved_date IS NULL). Q55 Verify it serves the "open tickets" query. Q56 Create an expression index on LOWER(email). Q57 Verify WHERE LOWER(email)='[email protected] ' now uses it. Q58 Create an expression index on (first_name || ' ' || last_name). Q59 Verify a full-name equality search uses it. Q60 Create an expression index on date_trunc('month', order_date::timestamp). Q61 Verify a monthly-bucket query uses it. Q62 Create a partial index for high-value orders (WHERE net_total > 50000). Q63 Verify a high-value-orders query uses it. Q64 Create an expression index on (price - cost_price) (margin). Q65 Verify a margin filter uses it. Q66 Create a partial UNIQUE-style index concept (note V3 dup emails block true UNIQUE). Q67 Create a partial index for recent orders (WHERE order_date >= DATE '2025-01-01'). Q68 Verify recent-orders queries use it. Q69 Create an expression index on EXTRACT(YEAR FROM order_date). Q70 Show why a range rewrite may beat the expression index anyway. Q71 Create a partial index on reviews WHERE rating <= 2 (negative reviews). Q72 Verify the negative-review query uses it. Q73 Create an expression index on regexp_replace(phone,'\\D','','g') (digits). Q74 Verify a normalized-phone lookup uses it. Q75 Drop all partial/expression demo indexes (cleanup). VERIFY & MEASURE Q76 EXPLAIN ANALYZE a point lookup before/after a single-col index; compare time. Q77 EXPLAIN ANALYZE a date-range before/after a composite; compare. Q78 Measure BUFFERS before/after indexing a hot query. Q79 Show a Sort disappears after a matching DESC composite. Q80 Confirm an Index Only Scan via a covering index. Q81 Confirm a partial index reduces scanned rows vs full index. Q82 Show the planner choosing Bitmap when selectivity is medium. Q83 Compare two candidate composites for the same query; pick the winner. Q84 Show that adding the wrong index doesn't change the plan (planner ignores). Q85 Measure the plan for a join before/after indexing the FK. Q86 Confirm ANALYZE was needed for the planner to use a new expression index. Q87 Show an Index Only Scan breaks when you add a non-covered column. Q88 Demonstrate leftmost-prefix: composite used for a-only, ignored for b-only. Q89 Measure ORDER BY ... LIMIT with vs without a matching index. Q90 Show a low-selectivity filter still Seq Scans despite an index. Q91 Compare single composite vs two singles (BitmapAnd) on a 2-predicate query. Q92 Verify a partial index is smaller (pg_relation_size) than the full one. Q93 Confirm dropping a redundant index leaves the plan unchanged. Q94 Show a covering index removing heap fetches (Heap Fetches=0 after VACUUM). Q95 Measure a GROUP BY before/after an index supporting it. Q96 Demonstrate the index that best serves a customer-orders-by-date page. Q97 Pick the right index for a "top products per brand by price" query. Q98 Verify the chosen index, then DROP it to keep RetailMart clean. Q99 Produce a before/after measurement table for one optimized query. Q100 Recommend a minimal index set (<=3) for the customer-360 query and justify each. Interview grade, edge cases
CONCEPTUAL Q1 Given WHERE a=? AND b BETWEEN ? AND ? ORDER BY c, design the ideal index. Q2 Equality-then-range-then-sort: why that column order in a composite. Q3 When does INCLUDE(cols) beat extending the key (cols)? Q4 How to detect a redundant index (leftmost-prefix duplication). Q5 Why are too many indexes harmful on a write-heavy table? Q6 When will the planner refuse a perfectly good index (low selectivity)? Q7 Partial index design: choosing the predicate to maximize hit-rate, minimize size. Q8 Covering index requirements for an Index Only Scan (+ visibility map). Q9 CREATE INDEX CONCURRENTLY: benefits, costs, failure mode (INVALID index). Q10 BitmapAnd vs single composite - when each wins. Q11 Why an expression index must match the query's exact expression. Q12 How to support both (a,b) and (a) lookups without two indexes. Q13 When a DESC index matters for ORDER BY ... DESC LIMIT. Q14 Index for a join: which side and which column. Q15 Why a GROUP BY on a high-cardinality column rarely benefits from an index. Q16 How statistics (n_distinct, MCV) influence whether your index is chosen. Q17 Trade-off of a wide covering index (size/write) vs Index Only Scan benefit. Q18 Detecting unused indexes (pg_stat_user_indexes idea; not installed metric here). Q19 When extended statistics beat adding an index (correlated columns). Q20 Why rewrite the query first, then index (analyst priority). Q21 Partial + covering combined: the "active rows fast read" pattern. Q22 How leading-column selectivity decides composite usefulness. Q23 Index maintenance: REINDEX vs bloat; when needed. Q24 Why a foreign key without an index hurts both joins and deletes. Q25 A decision tree: rewrite -> stats -> index -> MV (Topic 25). DESIGN THE INDEX FOR A QUERY Q26 SCENARIO: "Customer order history page" - WHERE cust_id=? ORDER BY order_date DESC LIMIT 20. Design + verify. Q27 Design for WHERE store_id=? AND order_date>=? (store recent orders). Q28 Design for WHERE brand_id=? AND price BETWEEN ? AND ?. Q29 Design for a join order_items.prod_id = products.product_id. Q30 Design for WHERE order_status='Cancelled' AND order_date>=? (partial). Q31 Design for "latest review per product" (product_id, review_date DESC). Q32 Design for WHERE agent_id=? AND status='Open' (tickets queue). Q33 Design for ORDER BY net_total DESC LIMIT 10 (global leaderboard). Q34 Design for WHERE customer_id=? on reviews (FK lookup). Q35 Design for a (region via store) revenue rollup access pattern. Q36 Design for WHERE LOWER(email)=? (expression index). Q37 Design for WHERE date_trunc('month',order_date::timestamp)=? (expression). Q38 Design for WHERE net_total>50000 (partial high-value). Q39 Design for a (warehouse_id, product_id, snapshot_date) point lookup. Q40 Design for WHERE campaign_id=? AND spend_date>=? on ads_spend. Q41 Design for "employees by store ordered by salary DESC". Q42 Design for WHERE resolved_date IS NULL (open tickets partial). Q43 Design a covering index so SELECT cust_id, net_total is Index Only. Q44 Design for WHERE call_reason=? AND call_start_time>=?. Q45 Design for WHERE pincode=? on addresses. Q46 Design for a recent-orders partial index (WHERE order_date >= '2025-01-01'). Q47 Design for "top products per brand by price" supporting query. Q48 Design for a normalized-phone lookup (expression on digits). Q49 Verify each designed index is actually used (EXPLAIN), then plan to drop. Q50 Drop all designed indexes (cleanup to keep RetailMart pristine). COVERING & PARTIAL IN PRACTICE Q51 Build a covering index for the customer-order-history page (INCLUDE net_total, order_status). Q52 Confirm Index Only Scan and Heap Fetches=0 (after VACUUM). Q53 Partial index: open tickets (resolved_date IS NULL) + verify size vs full. Q54 Partial index: Cancelled orders + verify usage and non-usage. Q55 Covering index for "orders list by store" (INCLUDE the displayed columns). Q56 Partial + covering: high-value orders with INCLUDE for the report columns. Q57 Expression + partial: LOWER(email) WHERE tier='Platinum'. Q58 Covering for a join + projection to avoid heap fetches. Q59 Partial index for recent reviews (review_date >= '2025-01-01'). Q60 Covering index enabling Index Only Scan for a GROUP BY cust_id SUM. Q61 Partial index for negative reviews (rating <= 2) + verify. Q62 Expression index for margin (price-cost_price) + verify a margin filter. Q63 Covering index for "latest order per customer" DISTINCT ON pattern. Q64 Partial index for active customers proxy (registration_date recent). Q65 Compare Index Only Scan vs Index Scan + heap for the same query. Q66 Show INCLUDE columns don't affect ordering but enable covering. Q67 Partial index predicate that the query must match exactly - prove it. Q68 Covering index for ads_spend rollups by platform. Q69 Partial index for unshipped orders (status in a set) - design. Q70 Verify a covering index's size vs a plain one (pg_relation_size). Q71 Show a partial index ignored when the query predicate doesn't match. Q72 Covering index for pay_slips lookups by employee+year. Q73 Combine partial + expression + covering in one purposeful index. Q74 Measure read speedup from the covering index (EXPLAIN ANALYZE). Q75 Drop all covering/partial demo indexes (cleanup). REDUNDANCY, LIMITS & WHEN-NOT-TO-INDEX Q76 SCENARIO: A table has (a), (a,b), (a,b,c) - identify the redundant ones to drop. Q77 Detect a single-column index made redundant by a composite. Q78 Show that a full-table SUM gains nothing from any index. Q79 Show a low-selectivity status filter Seq Scans despite an index. Q80 Show GROUP BY on a high-cardinality key doesn't benefit from an index. Q81 Identify which of 5 proposed indexes are worth keeping. Q82 Show extended statistics fixing an estimate instead of an index. Q83 Demonstrate a query that should be rewritten, not indexed. Q84 Estimate write-amplification from adding 3 indexes to a hot table (concept). Q85 Find overlapping indexes (same leading columns) to consolidate. Q86 Show a wide covering index whose write cost outweighs its read benefit. Q87 Decide single composite vs two singles for a 2-predicate query (measure). Q88 Detect an unused index candidate by query pattern (no query uses it). Q89 Show CONCURRENTLY avoids a long lock vs plain CREATE INDEX (concept). Q90 Decide when a partial index's predicate is too broad to help. Q91 Show a leading-wildcard search needs a different index type (trigram, Day-6 note). Q92 Show ORDER BY random() can't benefit from an index (use TABLESAMPLE). Q93 Identify an FK lacking an index that slows a frequent join. Q94 Quantify the rows-returned threshold where index beats Seq Scan. Q95 Decide between indexing vs materialized view for a nightly metric. Q96 Produce a "drop these redundant indexes" recommendation list. Q97 Produce a "create these 3 indexes" recommendation for the dashboard. Q98 Verify each recommended index helps, then DROP to keep RetailMart pristine. Q99 Write an indexing policy for the analytics team (what/when/how to verify). Q100 Full index audit: inventory, redundancies, missing, recommendations - sales schema. Production scenarios, optimisation
CONCEPTUAL Q1 Pick the index type for: equality, range, full-text, similarity, time-correlated append, geometry. Q2 B-Tree vs Hash: when is Hash worth it (equality-only, large keys)? Q3 GIN vs GiST for full-text/array/jsonb - read vs update tradeoffs. Q4 BRIN for huge append-only time-series - when it shines, when it fails. Q5 Covering index economics: read benefit vs write/size cost. Q6 Partial index design to maximize selectivity per byte. Q7 Expression index pitfalls: volatility, exact-match requirement. Q8 Multi-query index-set design: cover N queries with the fewest indexes. Q9 Write amplification: each index = extra work per INSERT/UPDATE/DELETE. Q10 Index bloat causes and REINDEX [CONCURRENTLY] remediation. Q11 HOT updates and how fewer indexed columns enable them (concept). Q12 fillfactor and update-heavy tables (concept). Q13 Extended statistics vs indexes for correlated predicates. Q14 Index-only scans + visibility map + VACUUM interplay. Q15 When BitmapAnd/Or of singles beats a tailored composite. Q16 Choosing leading column by selectivity AND by query shape. Q17 Partial unique indexes for "one active per group" (note V3 dup-email limit). Q18 CONCURRENTLY build/drop in production; INVALID index recovery. Q19 Index for ORDER BY + LIMIT (DESC composite) vs top-N window. Q20 When to push to a materialized view (Topic 25) instead of more indexes. Q21 Detecting unused/duplicate indexes systematically. Q22 Sizing indexes: pg_relation_size and budget per table. Q23 Covering vs INCLUDE vs key-extension decision matrix. Q24 Trigram (pg_trgm) indexes for LIKE '%x%' - extension + GIN/GiST. Q25 A staff-level "index review" checklist for a schema. INDEX-TYPE SELECTION Q26 B-Tree composite for (cust_id, order_date DESC) - create + verify Index-Only top-N. Q27 BRIN on web_events.page_views(view_timestamp) - create + verify on a range scan. Q28 Compare BRIN vs B-Tree size on the timestamp column (pg_relation_size). Q29 Hash index on a high-cardinality equality column - create + verify. Q30 Expression B-Tree on LOWER(email) - verify case-insensitive lookup. Q31 Expression B-Tree on date_trunc('month',order_date::timestamp) - verify. Q32 (practice) GIN on to_tsvector('english',review_text) for full-text - note + design. Q33 (practice) GIN trigram on (first_name||' '||last_name) for fuzzy - pg_trgm note. Q34 (practice) GiST trigram for ORDER BY name <-> 'query' - note + design. Q35 Partial B-Tree for open tickets (resolved_date IS NULL) - verify. Q36 Covering B-Tree (INCLUDE) for the orders list page - verify Index Only. Q37 B-Tree for FK join order_items.prod_id - verify Nested Loop/Index. Q38 BRIN on sales.orders(order_date) - does it help a wide range? Compare to B-Tree. Q39 Expression index on (price - cost_price) for margin filters - verify. Q40 Partial + expression: LOWER(email) WHERE tier='Platinum' - verify. Q41 B-Tree DESC for ORDER BY net_total DESC LIMIT - verify Sort removed. Q42 (practice) GIN on a JSONB column (Topic 24 data) - note only. Q43 Choose index type for "find similar product names" (trigram, practice). Q44 Choose index type for "orders in last 90 days" on a huge table (BRIN vs B-Tree). Q45 Choose index type for "exact email match" (B-Tree vs Hash) and justify. Q46 Covering index for a GROUP BY rollup enabling Index Only Scan. Q47 Partial index for high-value recent orders (two predicates). Q48 Compare planner choice with B-Tree present vs absent for a range. Q49 Verify each created index is used, then plan cleanup. Q50 Drop all created indexes (keep RetailMart pristine). MULTI-QUERY INDEX STRATEGY Q51 SCENARIO: Cover the 5 hottest analyst queries on sales.orders with the fewest indexes. Q52 Identify the minimal index set for customer-360 (orders, reviews, tickets joins). Q53 Design one composite that serves 3 different store queries (prefix reuse). Q54 Decide which queries share a leading column and can reuse one index. Q55 Avoid redundancy: pick (a,b,c) over (a)+(a,b)+(a,b,c). Q56 Index set for the monthly revenue dashboard (date + store + category access). Q57 Index set for the funnel/cohort queries (customer + date access). Q58 Index set for the support workload (agent + status + date). Q59 Index set for product analytics (brand + price + units joins). Q60 Decide covering vs non-covering per query in the set. Q61 Balance read benefit vs total write cost for the chosen set. Q62 Detect two proposed indexes that overlap and merge them. Q63 Decide which access patterns are better served by an MV (Topic 25). Q64 Prioritize index creation by query frequency x slowness. Q65 Design indexes for a join-heavy BI dashboard (FK coverage). Q66 Decide partial vs full for the "active rows" queries in the set. Q67 Index set for web_events analytics (session + timestamp + customer). Q68 Index set for inventory/snapshots lookups. Q69 Verify the whole proposed set against the real queries (EXPLAIN each). Q70 Estimate total index size for the proposed set (sum pg_relation_size). Q71 Show one index in the set being used by multiple queries (prefix reuse). Q72 Remove the least valuable index from the set and re-justify. Q73 Document the index set as a migration plan (for practice / prod). Q74 Re-verify after ANALYZE that all set indexes are chosen. Q75 Drop the entire experimental set (cleanup). MAINTENANCE & TRADEOFFS Q76 SCENARIO: A write-heavy table is slowing down - decide which indexes to drop and why. Q77 Measure index bloat conceptually and plan a REINDEX CONCURRENTLY. Q78 Show write-amplification: time an INSERT-like workload with N indexes (practice). Q79 Identify unused indexes to drop (by query-pattern reasoning). Q80 Decide fillfactor for an update-heavy table (concept). Q81 Plan CONCURRENTLY rebuilds to avoid locks (sequence of steps). Q82 Detect an INVALID index from a failed CONCURRENTLY build and fix. Q83 Trade covering width vs write cost for the orders list index. Q84 Decide when extended statistics replace a would-be index. Q85 Quantify the read win vs the write/size cost for one candidate index. Q86 Decide MV vs index for an expensive nightly aggregate. Q87 Plan an index lifecycle: create CONCURRENTLY, verify, monitor, drop if unused. Q88 Show VACUUM's role in keeping Index Only Scans effective. Q89 Decide whether to keep a partial index as data distribution shifts. Q90 Detect overlapping indexes and propose consolidation with sizes. Q91 Balance an index that helps reads but blocks HOT updates (concept). Q92 Establish a monitoring plan for index usage (pg_stat_user_indexes concept). Q93 Decide reindex cadence for a bloat-prone table. Q94 Right-size the index budget for the sales schema. Q95 Produce a "drop list" and a "keep list" with justifications. Q96 Plan a safe production rollout of 3 new indexes. Q97 Verify post-rollout that target queries improved (EXPLAIN ANALYZE). Q98 Document rollback (DROP INDEX) for each change. Q99 Write the team's indexing runbook (create/verify/monitor/retire). Q100 Full strategy memo: index set, types, maintenance, MV boundary - for the analytics platform.