Running totals with SUM OVER in SQL - Time & Space Complexity
We want to understand how the time to calculate running totals grows as the data size increases.
How does the database handle summing values step-by-step for many rows?
Analyze the time complexity of the following code snippet.
SELECT
order_id,
order_date,
amount,
SUM(amount) OVER (ORDER BY order_date) AS running_total
FROM orders;
This query calculates a running total of order amounts ordered by date.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Summing amounts for each row up to that row.
- How many times: For each row, the database sums all previous rows in order.
As the number of rows grows, the work to calculate each running total grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 55 sums (1+2+...+10) |
| 100 | About 5,050 sums |
| 1000 | About 500,500 sums |
Pattern observation: The total work grows much faster than the number of rows, roughly like the square of the input size.
Time Complexity: O(n^2)
This means the time to compute running totals grows roughly with the square of the number of rows.
[X] Wrong: "Calculating running totals is always fast and grows linearly with data size."
[OK] Correct: Because each running total sums all previous rows, the work adds up quickly, making it slower than just reading each row once.
Understanding how running totals scale helps you explain query performance and shows you can think about how databases handle data step-by-step.
"What if we added a PARTITION BY clause to reset running totals for each group? How would the time complexity change?"
Practice
SUM(amount) OVER (ORDER BY date) calculate?Solution
Step 1: Understand SUM() with OVER()
The SUM() function adds values, and OVER() defines how to apply it across rows.Step 2: Analyze ORDER BY in OVER()
ORDER BY date means the sum accumulates in date order, creating a running total.Final Answer:
A running total of the amount column ordered by date -> Option AQuick Check:
SUM() OVER(ORDER BY) = running total [OK]
- Thinking SUM() without OVER() gives running total
- Confusing running total with group total
- Ignoring ORDER BY inside OVER()
sales ordered by sale_date?Solution
Step 1: Identify correct use of SUM() OVER()
Running total requires SUM() OVER with ORDER BY clause inside OVER().Step 2: Check each option's syntax
SELECT sales, SUM(sales) OVER (ORDER BY sale_date) FROM sales_table; uses SUM(sales) OVER (ORDER BY sale_date), which is correct syntax for running total.Final Answer:
SELECT sales, SUM(sales) OVER (ORDER BY sale_date) FROM sales_table; -> Option BQuick Check:
SUM() OVER (ORDER BY ...) = running total syntax [OK]
- Using PARTITION BY instead of ORDER BY for running total
- Omitting OVER() clause
- Placing ORDER BY outside OVER()
sales_data with columns id, sale_date, and amount, what is the output of this query?SELECT id, sale_date, amount, SUM(amount) OVER (ORDER BY sale_date) AS running_total FROM sales_data ORDER BY id;
Assume the data:
id | sale_date | amount
1 | 2024-01-01 | 100
2 | 2024-01-03 | 200
3 | 2024-01-02 | 150Solution
Step 1: Order rows by sale_date for running total
Order by sale_date: id=1(2024-01-01), id=3(2024-01-02), id=2(2024-01-03).Step 2: Calculate running total in sale_date order
Running totals: 100 (id=1), 100+150=250 (id=3), 250+200=450 (id=2).Step 3: Output ordered by id
Order by id: id=1 (100), id=2 (450), id=3 (250).Final Answer:
Running totals: 100, 450, 250 ordered by id -> Option CQuick Check:
Running total sums in sale_date order, output sorted by id [OK]
- Assuming running total follows output ORDER BY
- Adding amounts in id order instead of sale_date order
- Confusing running total with simple sum
points ordered by game_date:SELECT player_id, points, SUM(points) OVER (PARTITION BY player_id) ORDER BY game_date FROM game_scores;
Solution
Step 1: Check placement of ORDER BY
ORDER BY for running total must be inside OVER(), not outside the function.Step 2: Understand correct syntax
Correct syntax: SUM(points) OVER (PARTITION BY player_id ORDER BY game_date).Final Answer:
ORDER BY clause is outside the OVER() function -> Option AQuick Check:
ORDER BY must be inside OVER() for running totals [OK]
- Placing ORDER BY outside OVER()
- Confusing PARTITION BY with GROUP BY
- Thinking SUM() can't be window function
region, sale_date, and amount. You want to calculate a running total of sales per region ordered by sale_date. Which query correctly achieves this?Solution
Step 1: Understand requirement for running total per region
We need to reset running total for each region, so PARTITION BY region is required.Step 2: Check ORDER BY for running total
ORDER BY sale_date inside OVER() ensures running total accumulates by date within each region.Step 3: Evaluate options
SELECT region, sale_date, amount, SUM(amount) OVER (PARTITION BY region ORDER BY sale_date) AS running_total FROM sales; correctly uses PARTITION BY region and ORDER BY sale_date inside SUM() OVER().Final Answer:
SELECT region, sale_date, amount, SUM(amount) OVER (PARTITION BY region ORDER BY sale_date) AS running_total FROM sales; -> Option DQuick Check:
PARTITION BY region + ORDER BY sale_date = running total per region [OK]
- Omitting PARTITION BY to separate groups
- Using GROUP BY instead of window functions
- Swapping ORDER BY columns inside OVER()
Ready to prove it?
Pass the test and this pattern moves unknown
