What if you could turn a messy multi-step data task into a clean, easy-to-follow recipe inside your database?
Why Multiple CTEs in one query in PostgreSQL? - Purpose & Use Cases
Imagine you have a big messy spreadsheet with many steps to calculate a final result. You copy data from one sheet to another, do some calculations, then copy again to another sheet for more work. It's confusing and easy to lose track.
Doing all these steps manually is slow and mistakes happen often. You might forget to update one sheet or mix up numbers. It's hard to see the whole process clearly, and fixing errors takes a lot of time.
Using multiple CTEs (Common Table Expressions) in one query lets you break down complex tasks into clear, named steps inside your database. Each step builds on the previous one, making your work organized and easy to follow.
SELECT * FROM sales WHERE date > '2023-01-01'; -- Then manually filter and join results in separate queries
WITH recent_sales AS ( SELECT * FROM sales WHERE date > '2023-01-01' ), total_by_customer AS ( SELECT customer_id, SUM(amount) AS total FROM recent_sales GROUP BY customer_id ) SELECT * FROM total_by_customer WHERE total > 1000;
It enables you to write clear, step-by-step queries that are easier to read, maintain, and debug, even for complex data tasks.
A store manager can quickly find customers who spent over $1000 in recent months by breaking the query into parts: first selecting recent sales, then summing totals per customer, and finally filtering big spenders.
Multiple CTEs let you organize complex queries into simple steps.
This reduces errors and makes your queries easier to understand.
You can reuse results from one step in the next, all in one query.
Practice
Solution
Step 1: Understand what CTEs do
CTEs let you write parts of a query separately with names, making complex queries easier to read.Step 2: Identify the purpose of multiple CTEs
Using multiple CTEs helps organize and simplify complex logic by splitting it into smaller named queries.Final Answer:
To break a complex query into smaller, readable parts -> Option DQuick Check:
Multiple CTEs = Query readability [OK]
- Confusing CTEs with permanent tables
- Thinking CTEs improve hardware speed
- Assuming CTEs create databases
cte1 and cte2 in one PostgreSQL query?Solution
Step 1: Recall correct CTE syntax
CTEs start with WITH, each named, followed by AS and a query in parentheses, separated by commas.Step 2: Check each option's syntax
WITH cte1 AS (SELECT * FROM table1), cte2 AS (SELECT * FROM table2) SELECT * FROM cte1 JOIN cte2 ON cte1.id = cte2.id; correctly uses commas, AS, and parentheses. Others miss parentheses or use wrong separators.Final Answer:
WITH cte1 AS (SELECT * FROM table1), cte2 AS (SELECT * FROM table2) SELECT * FROM cte1 JOIN cte2 ON cte1.id = cte2.id; -> Option AQuick Check:
Correct CTE syntax = WITH cte1 AS (SELECT * FROM table1), cte2 AS (SELECT * FROM table2) SELECT * FROM cte1 JOIN cte2 ON cte1.id = cte2.id; [OK]
- Omitting parentheses around CTE queries
- Using semicolons between CTEs
- Using '=' instead of AS
WITH cte1 AS (SELECT 1 AS num), cte2 AS (SELECT num * 2 AS double_num FROM cte1) SELECT * FROM cte2;
Solution
Step 1: Analyze cte1
cte1 returns one row with column num = 1.Step 2: Analyze cte2 using cte1
cte2 selects num * 2 as double_num, so double_num = 1 * 2 = 2.Step 3: Final SELECT from cte2
Only double_num column is selected, so output is [{double_num: 2}].Final Answer:
[{double_num: 2}] -> Option CQuick Check:
cte2 output columns = double_num [OK]
- Assuming cte2 includes all columns from cte1
- Expecting num column in final output
- Thinking query has syntax errors
WITH cte1 AS (SELECT id, name FROM users), cte2 AS (SELECT id, age FROM users) SELECT cte1.id, cte1.name, cte2.age FROM cte1 JOIN cte2 ON cte1.id = cte2.user_id;
Solution
Step 1: Check CTE definitions
Both cte1 and cte2 select id and other columns from users table correctly.Step 2: Check JOIN condition
Query joins on cte1.id = cte2.user_id, but cte2 has no user_id column, only id.Step 3: Identify error
Using cte2.user_id causes a column not found error.Final Answer:
Column cte2.user_id does not exist -> Option BQuick Check:
Check column names in JOIN = Column cte2.user_id does not exist [OK]
- Assuming user_id exists in cte2
- Thinking semicolons separate CTEs
- Believing CTEs cannot be joined
Solution
Step 1: Calculate average order per customer
WITH avg_orders AS (SELECT customer_id, AVG(amount) AS avg_amount FROM orders GROUP BY customer_id), high_avg AS (SELECT customer_id FROM avg_orders WHERE avg_amount > 100) SELECT * FROM high_avg; correctly uses AVG(amount) with GROUP BY customer_id in avg_orders CTE.Step 2: Filter customers with avg_amount > 100
WITH avg_orders AS (SELECT customer_id, AVG(amount) AS avg_amount FROM orders GROUP BY customer_id), high_avg AS (SELECT customer_id FROM avg_orders WHERE avg_amount > 100) SELECT * FROM high_avg; uses a second CTE high_avg to select customers meeting the condition.Step 3: Final SELECT returns customers with high average orders
WITH avg_orders AS (SELECT customer_id, AVG(amount) AS avg_amount FROM orders GROUP BY customer_id), high_avg AS (SELECT customer_id FROM avg_orders WHERE avg_amount > 100) SELECT * FROM high_avg; selects all from high_avg, giving correct result.Final Answer:
WITH avg_orders AS (SELECT customer_id, AVG(amount) AS avg_amount FROM orders GROUP BY customer_id), high_avg AS (SELECT customer_id FROM avg_orders WHERE avg_amount > 100) SELECT * FROM high_avg; -> Option AQuick Check:
Correct aggregation and filtering = WITH avg_orders AS (SELECT customer_id, AVG(amount) AS avg_amount FROM orders GROUP BY customer_id), high_avg AS (SELECT customer_id FROM avg_orders WHERE avg_amount > 100) SELECT * FROM high_avg; [OK]
- Using SUM instead of AVG for average calculation
- Missing GROUP BY clause
- Not filtering in a separate CTE
Ready to prove it?
Pass the test and this pattern moves unknown
