Window function vs GROUP BY mental model in SQL - Performance Comparison
We want to understand how the time it takes to run queries with window functions compares to those using GROUP BY.
How does the work grow as the data gets bigger for each method?
Analyze the time complexity of these two queries.
-- Using GROUP BY
SELECT department, COUNT(*) AS emp_count
FROM employees
GROUP BY department;
-- Using Window Function
SELECT employee_id, department, COUNT(*) OVER (PARTITION BY department) AS emp_count
FROM employees;
The first query groups rows by department and counts employees per group. The second counts employees per department but keeps all rows.
Look at what repeats in each query.
- Primary operation: Scanning all rows once to count employees.
- How many times: Each row is processed once; window function adds a step to assign counts back to each row.
As the number of employees (rows) grows, the work changes like this:
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 row scans and counts |
| 100 | About 100 row scans and counts |
| 1000 | About 1000 row scans and counts |
Both queries scan all rows once, but the window function also assigns counts back to each row, so it does a bit more work per row.
Time Complexity: O(n)
This means the time grows roughly in direct proportion to the number of rows in the table.
[X] Wrong: "Window functions always take much longer than GROUP BY because they do more work."
[OK] Correct: Both scan all rows once; window functions add some extra steps but still scale linearly, so the difference is usually small.
Understanding how these queries scale helps you explain your choices clearly and shows you know how databases handle data efficiently.
"What if we added an ORDER BY clause inside the window function? How would that affect the time complexity?"
Practice
GROUP BY clause and a window function in SQL?Solution
Step 1: Understand
GROUP BYbehaviorGROUP BYgroups rows by specified columns and returns one row per group with aggregated results.Step 2: Understand window function behavior
Window functions calculate aggregates over partitions but keep all original rows visible, adding summary columns.Final Answer:
GROUP BYgroups rows and returns one row per group; window functions keep all rows and add summary data. -> Option CQuick Check:
Window functions keep detail,GROUP BYgroups rows [OK]
- Thinking window functions reduce rows like GROUP BY
- Believing GROUP BY keeps all original rows
- Assuming window functions can't do aggregates
Solution
Step 1: Identify correct window function syntax
SELECT employee_id, sale_amount, SUM(sale_amount) OVER (PARTITION BY employee_id ORDER BY sale_date) AS running_total FROM sales; usesSUM() OVER (PARTITION BY ... ORDER BY ...), which is the correct syntax for running totals per employee.Step 2: Check other options for syntax errors
Options B, C, and D misuse GROUP BY or WINDOW clauses incorrectly, causing syntax errors or wrong logic.Final Answer:
The correct query: SELECT employee_id, sale_amount, SUM(sale_amount) OVER (PARTITION BY employee_id ORDER BY sale_date) AS running_total FROM sales; -> Option DQuick Check:
Window function syntax = SELECT employee_id, sale_amount, SUM(sale_amount) OVER (PARTITION BY employee_id ORDER BY sale_date) AS running_total FROM sales; [OK]
- Using GROUP BY with window function syntax
- Misplacing WINDOW clause
- Omitting OVER() for window functions
sales(employee_id, sale_amount) with data:1, 100
1, 200
2, 150
2, 50What is the output of this query?
SELECT employee_id, sale_amount, SUM(sale_amount) OVER (PARTITION BY employee_id) AS total_sales FROM sales ORDER BY employee_id, sale_amount;
Solution
Step 1: Calculate total sales per employee using window function
For employee 1: 100 + 200 = 300; for employee 2: 150 + 50 = 200.Step 2: Assign total_sales to each row without grouping
Each row for employee 1 shows 300, each for employee 2 shows 200, preserving all rows.Final Answer:
Rows show total sales per employee repeated: 1,100,300; 1,200,300; 2,50,200; 2,150,200. -> Option AQuick Check:
Window sums repeat per row, not grouped [OK]
- Confusing window sum with grouped sum
- Expecting fewer rows after window sum
- Mixing order of rows in output
SELECT employee_id, sale_amount, SUM(sale_amount) OVER (PARTITION BY employee_id ORDER BY sale_date) AS running_total FROM sales GROUP BY employee_id, sale_amount, sale_date;
What is the main issue with this query?
Solution
Step 1: Window functions execute after GROUP BY
Window functions are applied to the result set produced after GROUP BY and HAVING, so the query runs without syntax error.Step 2: GROUP BY distorts the running total
GROUP BY employee_id, sale_amount, sale_date collapses multiple rows sharing the same values in these columns into one row each before the window function computes the running total, leading to incorrect sums if duplicate combinations exist.Final Answer:
The query will run but return incorrect running totals. -> Option AQuick Check:
GROUP BY collapses rows before window functions run [OK]
- Assuming syntax error when mixing GROUP BY and window functions
- Thinking GROUP BY has no effect on subsequent window calculations
- Overlooking row collapse from GROUP BY before window execution
Solution
Step 1: Understand requirement to keep all individual sales
We want to keep each sale row visible, not collapse them by grouping.Step 2: Choose window function to add department average per row
Window functionAVG() OVER (PARTITION BY department_id)adds average without grouping rows.Step 3: Compare with other options
Options A, C, D use GROUP BY which collapses rows or require joins, making query complex.Final Answer:
Use window function to add department average per row, keeping all sales visible. -> Option BQuick Check:
Window functions keep detail and add group info [OK]
- Using GROUP BY and losing individual rows
- Overcomplicating with joins instead of window functions
- Grouping by employee instead of department
Ready to prove it?
Pass the test and this pattern moves unknown
