Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is the purpose of the pg_stat_user_indexes view in PostgreSQL?
It shows statistics about index usage for user-created indexes, helping you understand how often indexes are scanned or used.
Click to reveal answer
beginner
Which column in pg_stat_user_indexes tells you how many times an index was scanned?
The idx_scan column shows the number of index scans performed using that index.
Click to reveal answer
intermediate
How can you identify unused indexes using pg_stat_user_indexes?
Indexes with idx_scan value of zero have never been used for scanning and might be candidates for removal.
Click to reveal answer
intermediate
What does a high idx_tup_fetch value indicate in index statistics?
It indicates many table rows were fetched through the index scans, showing the index is actively helping queries.
Click to reveal answer
beginner
Why is it important to analyze index usage with pg_stat_user_indexes?
Because unused or rarely used indexes add overhead to writes and storage without benefit, so analyzing helps optimize performance.
Click to reveal answer
Which PostgreSQL view provides statistics about user index usage?
Apg_stat_activity
Bpg_stat_user_indexes
Cpg_indexes
Dpg_locks
✗ Incorrect
pg_stat_user_indexes tracks usage stats for user-created indexes.
If an index has idx_scan = 0, what does it mean?
AThe index is heavily used
BThe index is being rebuilt
CThe index is corrupted
DThe index has never been scanned
✗ Incorrect
An idx_scan of zero means no queries have used that index for scanning.
What does a high idx_tup_fetch value indicate?
AIndex is locked
BMany index scans failed
CMany rows fetched via index scans
DIndex is unused
✗ Incorrect
idx_tup_fetch counts rows fetched through index scans, showing active use.
Why might you want to drop an index with zero scans?
AIt wastes storage and slows writes
BIt slows down SELECT queries
CIt causes deadlocks
DIt prevents backups
✗ Incorrect
Unused indexes consume space and slow down data modifications without benefit.
Which command shows index usage statistics in PostgreSQL?
ASELECT * FROM pg_stat_user_indexes;
BSHOW INDEXES;
CEXPLAIN ANALYZE;
DSELECT * FROM pg_locks;
✗ Incorrect
pg_stat_user_indexes is the system view for index usage stats.
Explain how you can use pg_stat_user_indexes to find indexes that might be removed to improve performance.
Look for indexes with no scans and consider their cost.
You got /4 concepts.
Describe what information pg_stat_user_indexes provides about index usage and why it is useful.
Think about how index stats relate to query performance.
You got /4 concepts.
Practice
(1/5)
1. What does the idx_scan column in pg_stat_user_indexes represent?
easy
A. The number of times an index was used in a scan operation
B. The total size of the index in bytes
C. The number of rows in the indexed table
D. The creation date of the index
Solution
Step 1: Understand the purpose of pg_stat_user_indexes
This system view tracks usage statistics for user-created indexes in PostgreSQL.
Step 2: Identify the meaning of idx_scan
The idx_scan column counts how many times the index was used in scan operations, showing its usage frequency.
Final Answer:
The number of times an index was used in a scan operation -> Option A
Quick Check:
idx_scan = index usage count [OK]
Hint: Remember idx_scan counts index scans, not size or rows [OK]
Common Mistakes:
Confusing idx_scan with index size
Thinking idx_scan shows table row count
Assuming idx_scan is creation date
2. Which of the following SQL queries correctly retrieves index usage statistics from pg_stat_user_indexes for a table named customers?
easy
A. SELECT * FROM pg_stat_user_indexes WHERE relname = 'customers';
B. SELECT * FROM pg_stat_user_indexes WHERE tablename = 'customers';
C. SELECT * FROM pg_stat_user_indexes WHERE indexname = 'customers';
D. SELECT * FROM pg_stat_user_indexes WHERE table_name = 'customers';
Solution
Step 1: Check the column names in pg_stat_user_indexes
The correct column for the table name is relname, not tablename or table_name.
Step 2: Verify the query syntax
SELECT * FROM pg_stat_user_indexes WHERE relname = 'customers'; uses relname = 'customers', which is correct to filter indexes for the table named 'customers'.
Final Answer:
SELECT * FROM pg_stat_user_indexes WHERE relname = 'customers'; -> Option A
Quick Check:
Use relname to filter by table name [OK]
Hint: Use relname column to filter by table in pg_stat_user_indexes [OK]
Common Mistakes:
Using incorrect column names like tablename or table_name
Filtering by indexname instead of table name
Syntax errors in WHERE clause
3. Given the following query:
SELECT indexrelname, idx_scan FROM pg_stat_user_indexes WHERE relname = 'orders';
Which output correctly shows index usage if the table orders has two indexes orders_pkey with 150 scans and orders_date_idx with 0 scans?
medium
A. [{"indexrelname": "orders_pkey", "idx_scan": null}, {"indexrelname": "orders_date_idx", "idx_scan": null}]
B. [{"indexrelname": "orders_pkey", "idx_scan": 0}, {"indexrelname": "orders_date_idx", "idx_scan": 150}]
C. [{"indexrelname": "orders_pkey", "idx_scan": 150}]
D. [{"indexrelname": "orders_pkey", "idx_scan": 150}, {"indexrelname": "orders_date_idx", "idx_scan": 0}]
Solution
Step 1: Understand the query output
The query selects index names and their scan counts for the 'orders' table, so both indexes should appear with their respective scan counts.
Step 2: Match the scan counts to indexes
Given orders_pkey has 150 scans and orders_date_idx has 0, the output must show both with correct values.
Hint: Check idx_scan values match index names exactly [OK]
Common Mistakes:
Swapping scan counts between indexes
Showing null instead of zero for unused indexes
Omitting indexes with zero scans
4. You run this query to find unused indexes:
SELECT indexrelname FROM pg_stat_user_indexes WHERE idx_scan = 0;
But it returns no rows, even though you know some indexes are unused. What is the likely cause?
medium
A. The idx_scan column does not track usage
B. The query syntax is incorrect and missing a semicolon
C. The statistics collector has not been reset or updated recently
D. The table has no indexes at all
Solution
Step 1: Verify query correctness
The query syntax is correct and will return indexes with zero scans if any exist.
Step 2: Understand pg_stat_user_indexes behavior
Index usage stats depend on the statistics collector. If it was recently reset or the server restarted, idx_scan may be zeroed or not updated yet.
Final Answer:
The statistics collector has not been reset or updated recently -> Option C
Quick Check:
Stats collector state affects idx_scan values [OK]
Hint: Check if stats collector was reset before trusting idx_scan [OK]
Common Mistakes:
Assuming query syntax error causes no results
Thinking idx_scan never tracks usage
Believing no indexes exist without checking
5. You want to improve database performance by removing unused indexes. Which query helps you identify indexes that have never been scanned since the last stats reset, for table products?
hard
A. SELECT indexrelname FROM pg_stat_user_indexes WHERE idx_scan > 0 AND relname = 'products';
B. SELECT indexrelname FROM pg_stat_user_indexes WHERE relname = 'products' AND idx_scan = 0;
C. SELECT indexrelname FROM pg_stat_user_indexes WHERE relname = 'products' AND idx_tup_read = 0;
D. SELECT indexrelname FROM pg_stat_user_indexes WHERE relname = 'products' AND idx_scan IS NULL;
Solution
Step 1: Filter indexes by table name
Use relname = 'products' to focus on indexes for the products table.
Step 2: Identify unused indexes by scan count
Indexes with idx_scan = 0 have never been used since last stats reset, so they are candidates for removal.
Final Answer:
SELECT indexrelname FROM pg_stat_user_indexes WHERE relname = 'products' AND idx_scan = 0; -> Option B
Quick Check:
Unused indexes have idx_scan = 0 [OK]
Hint: Filter by relname and idx_scan = 0 to find unused indexes [OK]