Analyzing index usage with pg_stat in PostgreSQL - Step-by-Step Execution

Concept Flow - Analyzing index usage with pg_stat

Query pg_stat_user_indexes

↓

Check index scan counts

↓

Identify heavily used indexes

↓

Identify unused indexes

↓

Decide to keep or drop indexes

This flow shows how to query PostgreSQL's pg_stat_user_indexes to see which indexes are used and which are not, helping decide index maintenance.

Execution Sample

PostgreSQL

SELECT indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE schemaname = 'public';

This query lists index names and how many times each index was scanned in the public schema.

Execution Table

Step	Action	Query Result Sample	Explanation
1	Run query on pg_stat_user_indexes	[{"indexrelname": "users_pkey", "idx_scan": 1500}, {"indexrelname": "orders_idx", "idx_scan": 0}]	Fetch index usage stats for all indexes in public schema
2	Check idx_scan values	users_pkey: 1500, orders_idx: 0	High idx_scan means index is used; zero means unused
3	Identify unused indexes	orders_idx has idx_scan = 0	This index might be a candidate for removal
4	Decide action	Keep users_pkey, consider dropping orders_idx	Based on usage, keep or drop indexes to optimize performance
5	End	-	Analysis complete

💡 All indexes in public schema checked; usage counts analyzed to guide index maintenance decisions

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
indexrelname	N/A	["users_pkey", "orders_idx"]	["users_pkey", "orders_idx"]	["users_pkey", "orders_idx"]	["users_pkey", "orders_idx"]
idx_scan	N/A	[1500, 0]	[1500, 0]	[1500, 0]	[1500, 0]
unused_indexes	N/A	[]	[]	["orders_idx"]	["orders_idx"]

Key Moments - 2 Insights

Why does an index have idx_scan = 0 even if it exists?

An idx_scan of 0 means no queries have used that index since the last stats reset. See execution_table step 2 where orders_idx has 0 scans, indicating it might be unused.

Can an index with high idx_scan still be inefficient?

Yes, idx_scan shows usage count but not efficiency. An index might be used often but still slow queries if not well designed. This is beyond pg_stat_user_indexes and requires deeper analysis.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the idx_scan value for 'users_pkey'?

A 0

B 1500

C 500

D None

💡 Hint

Check the 'Query Result Sample' column in step 2 of execution_table

At which step do we identify unused indexes?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look for the step where idx_scan = 0 is noted for an index

If 'orders_idx' had idx_scan = 100, how would the unused_indexes variable change?

A It would include all indexes

B It would include 'orders_idx'

C It would be empty

D It would be null

💡 Hint

Refer to variable_tracker row 'unused_indexes' and how idx_scan = 0 triggers inclusion

Concept Snapshot

Use pg_stat_user_indexes to check index usage:
SELECT indexrelname, idx_scan FROM pg_stat_user_indexes WHERE schemaname = 'public';
idx_scan shows how many times an index was used.
Indexes with idx_scan = 0 may be unused and candidates for removal.
Regularly analyze to optimize database performance.

Full Transcript

This lesson shows how to analyze index usage in PostgreSQL using the pg_stat_user_indexes view. We run a query to get index names and their scan counts. By checking idx_scan values, we identify which indexes are used frequently and which are not used at all. Unused indexes have idx_scan = 0 and might be removed to improve performance. The execution table walks through each step from querying to deciding actions. Variable tracking shows how index names and scan counts are recorded and how unused indexes are identified. Key moments clarify common confusions about idx_scan meaning and index efficiency. The quiz tests understanding of idx_scan values, step identification, and variable changes. The snapshot summarizes the key points for quick reference.

Practice

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

1. Step 1: Understand the purpose of pg_stat_user_indexes

   This system view tracks usage statistics for user-created indexes in PostgreSQL.

2. 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.

3. Final Answer:

   The number of times an index was used in a scan operation -> Option A

4. 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

1. 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.

2. 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'.

3. Final Answer:

   SELECT * FROM pg_stat_user_indexes WHERE relname = 'customers'; -> Option A

4. 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

1. 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.

2. 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.

3. Final Answer:

   [{"indexrelname": "orders_pkey", "idx_scan": 150}, {"indexrelname": "orders_date_idx", "idx_scan": 0}] -> Option D

4. Quick Check:

   Index names match scan counts correctly [OK]

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

1. Step 1: Verify query correctness

   The query syntax is correct and will return indexes with zero scans if any exist.

2. 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.

3. Final Answer:

   The statistics collector has not been reset or updated recently -> Option C

4. 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

1. Step 1: Filter indexes by table name

   Use relname = 'products' to focus on indexes for the products table.

2. 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.

3. Final Answer:

   SELECT indexrelname FROM pg_stat_user_indexes WHERE relname = 'products' AND idx_scan = 0; -> Option B

4. Quick Check:

   Unused indexes have idx_scan = 0 [OK]

Hint: Filter by relname and idx_scan = 0 to find unused indexes [OK]

Common Mistakes:

• Using idx_scan > 0 to find unused indexes
• Confusing idx_tup_read with idx_scan
• Checking for NULL instead of zero scans