PARTITION BY for grouping windows in PostgreSQL - Time & Space Complexity
We want to understand how the time needed to run a query with PARTITION BY grows as the data gets bigger.
Specifically, how does grouping rows into partitions affect the work the database does?
Analyze the time complexity of the following code snippet.
SELECT employee_id, department_id, salary,
RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS salary_rank
FROM employees;
This query ranks employees by salary within each department using a window function with PARTITION BY.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The database groups rows by department_id, then sorts each group by salary.
- How many times: It does this for each partition (each department), processing all rows once.
As the number of employees grows, the database must sort more rows within each department.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 log 10 operations (sorting small groups) |
| 100 | About 100 log 100 operations (sorting larger groups) |
| 1000 | About 1000 log 1000 operations (sorting even larger groups) |
Pattern observation: The work grows a bit faster than the number of rows because sorting inside each partition takes more time as data grows.
Time Complexity: O(n log n)
This means the time to run the query grows a little faster than the number of rows because sorting happens within each group.
[X] Wrong: "PARTITION BY just groups rows and doesn't add any extra work."
[OK] Correct: Grouping means the database must sort or organize rows inside each group, which takes extra time especially as data grows.
Understanding how PARTITION BY affects query time helps you explain how databases handle grouped data efficiently, a useful skill for real projects and interviews.
"What if we removed ORDER BY inside the window function? How would the time complexity change?"
Practice
PARTITION BY clause do in a window function in PostgreSQL?Solution
Step 1: Understand the role of PARTITION BY
PARTITION BY groups rows so window functions calculate results within each group separately.Step 2: Differentiate from filtering and sorting
Filtering removes rows, sorting orders rows, but PARTITION BY only groups rows without removing or sorting them globally.Final Answer:
It divides the rows into groups to perform calculations within each group. -> Option BQuick Check:
PARTITION BY = grouping rows for window functions [OK]
- Confusing PARTITION BY with WHERE filtering
- Thinking PARTITION BY sorts all rows
- Assuming PARTITION BY removes duplicates
PARTITION BY in a window function?Solution
Step 1: Identify correct window function syntax
The correct syntax uses OVER() with PARTITION BY inside parentheses.Step 2: Check each option
SELECT col, SUM(value) OVER (PARTITION BY col ORDER BY date) FROM table; correctly uses SUM(value) OVER (PARTITION BY col ORDER BY date). Others misuse PARTITION BY outside OVER or with WHERE.Final Answer:
SELECT col, SUM(value) OVER (PARTITION BY col ORDER BY date) FROM table; -> Option AQuick Check:
Window functions use OVER() with PARTITION BY inside [OK]
- Placing PARTITION BY outside OVER()
- Using WHERE instead of PARTITION BY
- Omitting OVER() entirely
sales with columns region, month, and amount, what will this query return?SELECT region, month, amount, SUM(amount) OVER (PARTITION BY region ORDER BY month) AS running_total FROM sales ORDER BY region, month;
Solution
Step 1: Understand SUM() OVER with PARTITION BY and ORDER BY
SUM() OVER (PARTITION BY region ORDER BY month) calculates a running total per region ordered by month.Step 2: Analyze the output
Each row shows the cumulative sum of amount for that region up to the current month.Final Answer:
A running total of sales amount per region ordered by month. -> Option DQuick Check:
PARTITION BY groups, ORDER BY defines running total order [OK]
- Thinking it sums all regions together
- Ignoring ORDER BY for running total
- Assuming syntax error with ORDER BY in window
SELECT employee_id, department, RANK() OVER PARTITION BY department ORDER BY salary DESC FROM employees;
Solution
Step 1: Check window function syntax
Window functions require OVER() with parentheses enclosing PARTITION BY and ORDER BY.Step 2: Identify missing parentheses
The query misses parentheses after OVER, causing syntax error.Final Answer:
Missing parentheses around PARTITION BY and ORDER BY clauses. -> Option AQuick Check:
OVER() must enclose PARTITION BY and ORDER BY [OK]
- Omitting parentheses after OVER
- Thinking ORDER BY is not allowed in window functions
- Assuming all columns must be in PARTITION BY
PARTITION BY to achieve this?Solution
Step 1: Use AVG() with PARTITION BY category
AVG(amount) OVER (PARTITION BY category) calculates average sales per category.Step 2: Use RANK() with PARTITION BY category ordered by sale_date
RANK() OVER (PARTITION BY category ORDER BY sale_date) ranks sales within each category by date.Step 3: Verify syntax correctness
SELECT product, category, sale_date, amount, AVG(amount) OVER (PARTITION BY category), RANK() OVER (PARTITION BY category ORDER BY sale_date) FROM sales; uses correct OVER() syntax with PARTITION BY and ORDER BY clauses for both functions.Final Answer:
SELECT product, category, sale_date, amount, AVG(amount) OVER (PARTITION BY category), RANK() OVER (PARTITION BY category ORDER BY sale_date) FROM sales; -> Option CQuick Check:
Use PARTITION BY category inside OVER() for grouping [OK]
- Omitting OVER() or PARTITION BY
- Mixing PARTITION BY columns incorrectly
- Using PARTITION BY without parentheses
Ready to prove it?
Pass the test and this pattern moves unknown
