SELECT with PostgreSQL-specific features - Time & Space Complexity
We want to understand how the time to run a SELECT query with PostgreSQL-specific features changes as the data grows.
Specifically, how does the query time grow when using features like window functions or DISTINCT ON?
Analyze the time complexity of the following PostgreSQL query.
SELECT DISTINCT ON (category)
category,
product_name,
price,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) AS rank
FROM products
ORDER BY category, price DESC;
This query selects the most expensive product per category using DISTINCT ON and a window function.
Look for repeated actions in the query execution.
- Primary operation: Scanning all rows in the products table.
- How many times: Once for the scan, then sorting and partitioning by category for the window function and DISTINCT ON.
As the number of products grows, the query must process more rows and sort them.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 rows scanned and sorted |
| 100 | About 100 rows scanned and sorted |
| 1000 | About 1000 rows scanned and sorted |
Pattern observation: The work grows roughly in proportion to the number of rows because sorting and partitioning happen on all rows.
Time Complexity: O(n log n)
This means the time grows a bit faster than the number of rows because sorting is involved.
[X] Wrong: "Using DISTINCT ON or window functions makes the query run in constant time regardless of data size."
[OK] Correct: These features still require scanning and sorting the data, so the time grows with the number of rows.
Understanding how PostgreSQL-specific features affect query time helps you explain your choices clearly and shows you know how databases handle data behind the scenes.
"What if we added an index on the category column? How would that change the time complexity?"
Practice
LIMIT clause do in a PostgreSQL SELECT query?Solution
Step 1: Understand the purpose of LIMIT
The LIMIT clause is used to specify the maximum number of rows to return from a query result.Step 2: Compare with other options
Sorting is done by ORDER BY, removing duplicates by DISTINCT, and combining tables by JOIN, so these are not correct.Final Answer:
It restricts the number of rows returned by the query. -> Option BQuick Check:
LIMIT = restrict rows [OK]
- Confusing LIMIT with ORDER BY
- Thinking LIMIT removes duplicates
- Mixing LIMIT with JOIN functionality
customers?Solution
Step 1: Recall correct DISTINCT syntax
In PostgreSQL, DISTINCT comes immediately after SELECT and before the column list.Step 2: Validate each option
SELECT DISTINCT city FROM customers; correctly places DISTINCT after SELECT. Options A, B, and D misuse DISTINCT placement causing syntax errors.Final Answer:
SELECT DISTINCT city FROM customers; -> Option CQuick Check:
SELECT DISTINCT = correct syntax [OK]
- Placing DISTINCT after column names
- Using DISTINCT after FROM clause
- Misordering keywords causing syntax errors
products with columns id, name, and price, what will this query return?SELECT name FROM products ORDER BY price DESC LIMIT 2;
Solution
Step 1: Understand ORDER BY with DESC
ORDER BY price DESC sorts products from highest to lowest price.Step 2: Apply LIMIT 2
LIMIT 2 restricts the output to only the first two rows after sorting, so the two most expensive products.Final Answer:
The two products with the highest prices. -> Option DQuick Check:
ORDER BY DESC + LIMIT = top rows [OK]
- Thinking LIMIT returns lowest prices
- Believing LIMIT causes syntax error with ORDER BY
- Ignoring DESC means descending order
SELECT DISTINCT name, price FROM products LIMIT;
Solution
Step 1: Check LIMIT usage
LIMIT must be followed by a number indicating how many rows to return; here it is missing.Step 2: Validate other parts
DISTINCT can be used with multiple columns, WHERE is optional, and table name is present as products.Final Answer:
LIMIT requires a number to specify how many rows to return. -> Option AQuick Check:
LIMIT needs a number [OK]
- Omitting number after LIMIT
- Thinking DISTINCT can't use multiple columns
- Assuming WHERE is mandatory with LIMIT
employees table with column salary. Which query correctly achieves this in PostgreSQL?Solution
Step 1: Understand OFFSET and LIMIT
OFFSET 2 skips the first two highest salaries, LIMIT 2 returns the next two rows.Step 2: Check ORDER BY direction
ORDER BY salary DESC sorts salaries from highest to lowest, so OFFSET 2 skips top two highest.Step 3: Validate options
SELECT salary FROM employees ORDER BY salary DESC LIMIT 2 OFFSET 2; correctly orders DESC, uses LIMIT 2 and OFFSET 2. SELECT salary FROM employees ORDER BY salary ASC LIMIT 2 OFFSET 3; orders ASC (wrong direction), C misplaces ORDER BY, D places ORDER BY after LIMIT (syntax error).Final Answer:
SELECT salary FROM employees ORDER BY salary DESC LIMIT 2 OFFSET 2; -> Option AQuick Check:
OFFSET skips rows, LIMIT picks next [OK]
- Using ASC instead of DESC for highest values
- Placing ORDER BY after LIMIT
- Confusing OFFSET number with row count
Ready to prove it?
Pass the test and this pattern moves unknown
