EXPLAIN ANALYZE for actual execution in PostgreSQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Output of EXPLAIN ANALYZE on a simple SELECT

Given the table employees(id INT, name TEXT, salary INT) with 3 rows, what does EXPLAIN ANALYZE SELECT * FROM employees WHERE salary > 50000; output?

PostgreSQL

EXPLAIN ANALYZE SELECT * FROM employees WHERE salary > 50000;

A The result rows of the SELECT query without any plan or timing information.

B Only the query plan without any timing or row count details.

C An error because EXPLAIN ANALYZE cannot be used with SELECT statements.

D A query plan showing a sequential scan with actual time and rows filtered, plus total execution time.

💡 Hint

EXPLAIN ANALYZE runs the query and shows actual execution details.

EXPLAIN ANALYZE executes the query and returns the query plan with actual timing and row counts, helping understand performance.

🧠 Conceptual

intermediate

Purpose of EXPLAIN ANALYZE in PostgreSQL

What is the main purpose of using EXPLAIN ANALYZE in PostgreSQL?

A To modify the query execution plan automatically for optimization.

B To show the estimated query plan without running the query.

C To execute the query and show the actual runtime statistics and plan.

D To display only the query syntax errors before execution.

💡 Hint

Think about what extra information EXPLAIN ANALYZE provides compared to EXPLAIN.

EXPLAIN ANALYZE runs the query and shows actual execution times and row counts, unlike EXPLAIN which only shows estimated plans.

📝 Syntax

advanced

Identify the correct EXPLAIN ANALYZE syntax

Which of the following is the correct syntax to get actual execution details for a query in PostgreSQL?

A EXPLAIN ANALYZE SELECT * FROM users WHERE age > 30;

B ANALYZE EXPLAIN SELECT * FROM users WHERE age > 30;

C EXPLAIN SELECT * FROM users WHERE age > 30 ANALYZE;

D SELECT EXPLAIN ANALYZE * FROM users WHERE age > 30;

💡 Hint

EXPLAIN ANALYZE is a prefix before the query.

The correct syntax is to write EXPLAIN ANALYZE before the query to run it and show execution details.

❓ optimization

advanced

Using EXPLAIN ANALYZE to find slow query parts

You run EXPLAIN ANALYZE on a complex query and see a nested loop join taking most of the time. What should you do next?

A Rewrite the query to remove all joins.

B Add indexes on join columns to speed up the nested loop.

C Ignore the nested loop because it is always the fastest join method.

D Disable EXPLAIN ANALYZE and run EXPLAIN only.

💡 Hint

Think about how indexes affect join performance.

Nested loops can be slow without indexes; adding indexes on join keys often improves performance.

🔧 Debug

expert

Diagnosing unexpected EXPLAIN ANALYZE output

You run EXPLAIN ANALYZE on a query but notice the actual execution time is much higher than expected. Which of these is NOT a likely cause?

A The EXPLAIN ANALYZE output is cached and shows old timings.

B The query is blocked by locks causing delays.

C The statistics used by the planner are outdated.

D The query plan uses sequential scans on large tables.

💡 Hint

Consider how EXPLAIN ANALYZE works and what affects timing.

EXPLAIN ANALYZE runs the query fresh each time; it does not cache timings. Other options can cause slow execution.

Practice

1. What is the main purpose of using EXPLAIN ANALYZE in PostgreSQL?

easy

A. To only check the syntax of the SQL query without running it

B. To run the query and show the actual execution plan with timing details

C. To delete data from the database safely

D. To create a backup of the database

Solution

1. Step 1: Understand what EXPLAIN ANALYZE does

   It runs the SQL query and collects detailed information about how the database executes it, including timing and row counts.

2. Step 2: Compare with other options

   Options A, C, and D describe different actions unrelated to EXPLAIN ANALYZE's purpose.

3. Final Answer:

   To run the query and show the actual execution plan with timing details -> Option B

4. Quick Check:

   EXPLAIN ANALYZE = actual execution plan with timing [OK]

Hint: EXPLAIN ANALYZE runs query and shows real execution details [OK]

Common Mistakes:

• Thinking EXPLAIN ANALYZE only checks syntax
• Confusing it with backup or delete commands
• Assuming it does not run the query

2. Which of the following is the correct syntax to get the actual execution plan of a query SELECT * FROM users; using EXPLAIN ANALYZE?

easy

A. EXPLAIN SELECT * FROM users;

B. EXPLAIN RUN SELECT * FROM users;

C. EXPLAIN ANALYZE SELECT * FROM users;

D. ANALYZE EXPLAIN SELECT * FROM users;

Solution

1. Step 1: Recall the correct EXPLAIN ANALYZE syntax

   The correct syntax is to write EXPLAIN ANALYZE followed by the query to run and analyze.

2. Step 2: Check each option

   EXPLAIN SELECT * FROM users; misses ANALYZE, so it only shows estimated plan. ANALYZE EXPLAIN SELECT * FROM users; reverses keywords incorrectly. EXPLAIN RUN SELECT * FROM users; uses an invalid keyword RUN.

3. Final Answer:

   EXPLAIN ANALYZE SELECT * FROM users; -> Option C

4. Quick Check:

   EXPLAIN ANALYZE + query = correct syntax [OK]

Hint: EXPLAIN ANALYZE before query runs it and shows plan [OK]

Common Mistakes:

• Omitting ANALYZE keyword
• Swapping EXPLAIN and ANALYZE order
• Using invalid keywords like RUN

3. Given the query EXPLAIN ANALYZE SELECT * FROM orders WHERE order_id = 10;, which part of the output tells you how many rows were actually returned?

medium

A. The "Buffers" section

B. The "Estimated Rows" value in the output

C. The "Planning Time" value

D. The "Actual Rows" value in the output

Solution

1. Step 1: Understand EXPLAIN ANALYZE output fields

   "Actual Rows" shows the real number of rows returned by each step during execution.

2. Step 2: Differentiate from other fields

   "Estimated Rows" is the planner's guess before running. "Planning Time" is time spent planning. "Buffers" shows disk usage, not row count.

3. Final Answer:

   The "Actual Rows" value in the output -> Option D

4. Quick Check:

   Actual Rows = real returned rows [OK]

Hint: "Actual Rows" shows real returned rows, not estimates [OK]

Common Mistakes:

• Confusing estimated rows with actual rows
• Looking at planning time for row count
• Ignoring actual execution details

4. You run ANALYZE EXPLAIN SELECT * FROM products WHERE price > 100; but get an error: ERROR: syntax error at or near "EXPLAIN". What is the likely cause?

medium

A. You wrote ANALYZE before EXPLAIN

B. You forgot the semicolon at the end

C. You used EXPLAIN without ANALYZE

D. You ran the query without EXPLAIN

Solution

1. Step 1: Analyze the error message

   The error points to a syntax problem near "EXPLAIN" which suggests wrong keyword order.

2. Step 2: Check correct keyword order

   The correct order is EXPLAIN ANALYZE, not ANALYZE EXPLAIN. Writing ANALYZE first causes syntax error.

3. Final Answer:

   You wrote ANALYZE before EXPLAIN -> Option A

4. Quick Check:

   EXPLAIN must come before ANALYZE [OK]

Hint: EXPLAIN always comes before ANALYZE in syntax [OK]

Common Mistakes:

• Swapping EXPLAIN and ANALYZE keywords
• Missing semicolon (usually different error)
• Running query without EXPLAIN ANALYZE

5. You want to optimize a slow query joining customers and orders. Using EXPLAIN ANALYZE, you see a sequential scan on orders despite an index on customer_id. What should you check or do next?

hard

A. Check if statistics are outdated and run ANALYZE orders;

B. Drop the index on customer_id to force sequential scan

C. Rewrite the query without JOIN to avoid scans

D. Increase the database cache size to ignore indexes

Solution

1. Step 1: Understand why index might be ignored

   If statistics are outdated, the planner may wrongly choose a sequential scan instead of using the index.

2. Step 2: Use ANALYZE to update statistics

   Running ANALYZE orders; updates table statistics so planner can make better decisions.

3. Final Answer:

   Check if statistics are outdated and run ANALYZE orders; -> Option A

4. Quick Check:

   Update stats with ANALYZE to help planner use indexes [OK]

Hint: Run ANALYZE to update stats so planner uses indexes [OK]

Common Mistakes:

• Dropping useful indexes
• Ignoring statistics update
• Trying to avoid JOINs instead of fixing plan