CTE vs subquery performance in PostgreSQL - Practice Questions

Challenge - 5 Problems

❓ query_result

intermediate

Output of CTE vs Subquery with Aggregation

Given the table sales with columns region and amount, what is the output of these two queries?

Query 1 uses a CTE:

WITH regional_totals AS (
  SELECT region, SUM(amount) AS total
  FROM sales
  GROUP BY region
)
SELECT * FROM regional_totals WHERE total > 1000;

Query 2 uses a subquery:

SELECT region, total FROM (
  SELECT region, SUM(amount) AS total
  FROM sales
  GROUP BY region
) AS sub WHERE total > 1000;

Assuming the sales table has:

region | amount
-------+--------
East   | 500
East   | 600
West   | 400
West   | 300
South  | 1200

A Empty result for Query 1; [{"region": "South", "total": 1200}] for Query 2

B [{"region": "East", "total": 1100}, {"region": "South", "total": 1200}] for both queries

C Both queries return empty result

D [{"region": "East", "total": 1100}] for Query 1; empty result for Query 2

💡 Hint

Both CTE and subquery here calculate the same aggregation and filter the same way.

Both queries compute the sum of amounts grouped by region, then filter regions with totals over 1000. The results are the same: East (1100) and South (1200).

🧠 Conceptual

intermediate

Performance difference between CTE and subquery in PostgreSQL before version 12

Which statement best describes the performance behavior of CTEs compared to subqueries in PostgreSQL before version 12?

A CTEs act as optimization fences and are materialized, which can hurt performance.

B CTEs are always inlined and optimized like subqueries.

C Subqueries are materialized by default, while CTEs are always optimized away.

D Both CTEs and subqueries are always materialized and never optimized.

💡 Hint

Think about how PostgreSQL treats CTEs as separate query blocks before version 12.

Before PostgreSQL 12, CTEs are optimization fences and are materialized, meaning the database computes and stores the CTE result before the outer query runs. This can hurt performance compared to subqueries, which can be inlined and optimized.

📝 Syntax

advanced

Identify the syntax error in CTE usage

Which of the following CTE usages will cause a syntax error in PostgreSQL?

A WITH cte AS (SELECT id FROM users) SELECT id FROM cte;

B WITH cte AS (SELECT * FROM users) SELECT * FROM cte;

C WITH cte AS SELECT * FROM users SELECT * FROM cte;

D WITH cte AS (SELECT * FROM users WHERE active = true) SELECT * FROM cte;

💡 Hint

Check the parentheses around the CTE query.

Option C is missing parentheses around the CTE query, which is required syntax in PostgreSQL.

❓ optimization

advanced

Optimizing repeated subqueries vs CTEs

You have a complex subquery used multiple times in a large query. Which approach is generally better for performance in PostgreSQL 13 and later?

A Repeat the subquery inline multiple times for better optimization.

B Avoid CTEs because they always cause performance degradation.

C Use temporary tables instead of CTEs or subqueries.

D Use a CTE to compute the subquery once and reuse the result.

💡 Hint

PostgreSQL 12+ can inline CTEs unless marked MATERIALIZED.

In PostgreSQL 12 and later, CTEs can be inlined or materialized. Using a CTE to compute a complex subquery once and reuse it can improve performance by avoiding repeated computation.

🔧 Debug

expert

Why does this query with CTE run slower than the subquery version?

Consider these two queries on a large table orders with an index on customer_id:

Query 1 (CTE):

WITH recent_orders AS (
  SELECT * FROM orders WHERE order_date > '2024-01-01'
)
SELECT customer_id, COUNT(*) FROM recent_orders GROUP BY customer_id;

Query 2 (subquery):

SELECT customer_id, COUNT(*) FROM (
  SELECT * FROM orders WHERE order_date > '2024-01-01'
) AS recent_orders GROUP BY customer_id;

Query 1 runs significantly slower than Query 2. What is the most likely reason?

A The CTE forces materialization, preventing index usage and causing a full scan.

B The subquery version has a syntax error and does not run.

C The CTE query is missing a GROUP BY clause causing incorrect aggregation.

D The subquery version disables parallelism causing slower execution.

💡 Hint

Think about how PostgreSQL treats CTEs as optimization fences before version 12 and how that affects index usage.

The CTE is materialized as a temporary result, which disables index scans and parallelism on the base table. The subquery can be optimized and use indexes, making it faster.

Practice

1. What is a common performance difference between CTEs and subqueries in PostgreSQL before version 12?

easy

A. CTEs and subqueries have identical performance.

B. Subqueries always run slower than CTEs.

C. CTEs act as optimization fences, potentially slowing queries.

D. Subqueries cannot be used inside SELECT statements.

Solution

1. Step 1: Understand CTE behavior in PostgreSQL before v12

   CTEs are treated as optimization fences, meaning the planner executes them separately and does not optimize across them.

2. Step 2: Compare with subqueries

   Subqueries can be inlined and optimized with the rest of the query, often leading to better performance.

3. Final Answer:

   CTEs act as optimization fences, potentially slowing queries. -> Option C

4. Quick Check:

   CTEs before v12 block optimization = A [OK]

Hint: Remember: CTEs block optimization before PostgreSQL 12 [OK]

Common Mistakes:

• Thinking subqueries are always slower
• Assuming CTEs and subqueries perform the same
• Believing subqueries can't be inside SELECT

2. Which of the following is the correct syntax to define a CTE in PostgreSQL?

easy

A. WITH cte_name AS (SELECT * FROM table_name) SELECT * FROM cte_name;

B. SELECT * FROM table_name WITH cte_name AS ();

C. CREATE CTE cte_name SELECT * FROM table_name;

D. WITH (SELECT * FROM table_name) AS cte_name SELECT * FROM cte_name;

Solution

1. Step 1: Recall CTE syntax

   CTEs start with WITH, followed by the CTE name, AS, and a query in parentheses.

2. Step 2: Validate each option

   WITH cte_name AS (SELECT * FROM table_name) SELECT * FROM cte_name; matches the correct syntax. Options A, B, and C have incorrect order or keywords.

3. Final Answer:

   WITH cte_name AS (SELECT * FROM table_name) SELECT * FROM cte_name; -> Option A

4. Quick Check:

   CTE syntax starts with WITH name AS (query) [OK]

Hint: CTE syntax always starts with WITH name AS (query) [OK]

Common Mistakes:

• Placing WITH after SELECT
• Using CREATE keyword for CTE
• Misplacing parentheses

3. Given the following queries, which one is likely to run faster in PostgreSQL 11?

-- Query 1 (CTE):
WITH recent_orders AS (SELECT * FROM orders WHERE order_date > '2024-01-01')
SELECT customer_id, COUNT(*) FROM recent_orders GROUP BY customer_id;

-- Query 2 (Subquery):
SELECT customer_id, COUNT(*) FROM (SELECT * FROM orders WHERE order_date > '2024-01-01') AS recent_orders GROUP BY customer_id;

medium

A. Query 1 runs faster because CTEs are always optimized.

B. Query 2 runs faster because subqueries allow better optimization in PostgreSQL 11.

C. Both queries run at the same speed.

D. Query 1 will cause a syntax error.

Solution

1. Step 1: Understand PostgreSQL 11 optimization

   In PostgreSQL 11, CTEs act as optimization fences, so Query 1 executes the CTE separately.

2. Step 2: Compare with subquery behavior

   Subqueries can be inlined and optimized with the main query, so Query 2 can be faster.

3. Final Answer:

   Query 2 runs faster because subqueries allow better optimization in PostgreSQL 11. -> Option B

4. Quick Check:

   PostgreSQL 11: subqueries optimize better than CTEs [OK]

Hint: Before v12, subqueries usually run faster than CTEs [OK]

Common Mistakes:

• Assuming CTEs always optimize well
• Thinking both queries have same speed
• Believing Query 1 has syntax error

4. Identify the error in this query using a CTE in PostgreSQL:

WITH recent_orders AS SELECT * FROM orders WHERE order_date > '2024-01-01'
SELECT * FROM recent_orders;

medium

A. Missing parentheses around the CTE query.

B. CTE name is invalid.

C. Missing semicolon after CTE.

D. CTEs cannot filter by date.

Solution

1. Step 1: Check CTE syntax

   CTE query must be enclosed in parentheses after AS keyword.

2. Step 2: Identify the missing parentheses

   The query lacks parentheses around SELECT * FROM orders WHERE ...

3. Final Answer:

   Missing parentheses around the CTE query. -> Option A

4. Quick Check:

   CTE query must be in parentheses [OK]

Hint: Always put CTE query inside parentheses after AS [OK]

Common Mistakes:

• Omitting parentheses around CTE query
• Thinking semicolon is required after CTE
• Believing CTE names can't be simple

5. You want to optimize a complex query in PostgreSQL 13 that uses multiple CTEs and subqueries. Which approach is best to improve performance?

hard

A. Avoid both CTEs and subqueries; use temporary tables instead.

B. Replace all CTEs with subqueries to allow better optimization.

C. Use only CTEs because subqueries are deprecated in PostgreSQL 13.

D. Keep CTEs because PostgreSQL 13 can inline them, improving speed.

Solution

1. Step 1: Understand PostgreSQL 13 CTE behavior

   Starting with PostgreSQL 12, CTEs can be inlined and optimized like subqueries.

2. Step 2: Evaluate optimization strategies

   Replacing CTEs with subqueries is not necessary; keeping CTEs maintains readability and performance.

3. Final Answer:

   Keep CTEs because PostgreSQL 13 can inline them, improving speed. -> Option D

4. Quick Check:

   PostgreSQL 12+ inlines CTEs for better optimization [OK]

Hint: PostgreSQL 12+ optimizes CTEs like subqueries [OK]

Common Mistakes:

• Thinking subqueries are deprecated
• Replacing CTEs blindly without testing
• Assuming temporary tables always improve speed