Why result control matters in PostgreSQL - Performance Analysis
When working with database queries, controlling the results returned is important for performance.
We want to understand how the size of the result affects the time it takes to get data.
Analyze the time complexity of the following query that limits results.
SELECT *
FROM employees
WHERE department = 'Sales'
ORDER BY hire_date DESC
LIMIT 10;
This query fetches the 10 most recently hired employees in the Sales department.
Look at what repeats as data grows.
- Primary operation: Scanning employees in Sales and sorting by hire date.
- How many times: Depends on number of Sales employees before limiting to 10.
As the number of Sales employees grows, the database must check more rows and sort more data.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Checking and sorting about 10 rows |
| 100 | Checking and sorting about 100 rows |
| 1000 | Checking and sorting about 1000 rows |
Pattern observation: More rows mean more work before picking the top 10 results.
Time Complexity: O(n log n)
This means the time grows faster than the number of rows because sorting takes more steps as data grows.
[X] Wrong: "Limiting results to 10 means the query always runs fast regardless of data size."
[OK] Correct: The database still processes all matching rows before sorting and limiting, so large data means more work.
Understanding how result size affects query time helps you write efficient queries and explain performance in real projects.
"What if we added an index on hire_date? How would the time complexity change?"
Practice
Solution
Step 1: Understand what result control does
Result control means filtering, sorting, and limiting data to get clear results.Step 2: Identify the benefit of result control
It helps avoid confusion and saves time by showing only useful data.Final Answer:
It helps you get clear and useful data by filtering and sorting. -> Option CQuick Check:
Result control = clear, useful data [OK]
- Thinking result control deletes data
- Believing it slows down queries
- Assuming it fixes data errors automatically
Solution
Step 1: Recall PostgreSQL syntax for limiting rows
PostgreSQL uses LIMIT to restrict the number of rows returned.Step 2: Compare options with correct syntax
SELECT * FROM table LIMIT 5; uses LIMIT 5, which is correct. SELECT * FROM table TOP 5; uses TOP, which is SQL Server syntax. SELECT * FROM table FETCH FIRST 5; is invalid syntax (missing ROWS ONLY). SELECT * FROM table WHERE ROWS = 5; is invalid syntax.Final Answer:
SELECT * FROM table LIMIT 5; -> Option DQuick Check:
LIMIT 5 limits rows in PostgreSQL [OK]
- Using TOP instead of LIMIT
- Trying FETCH FIRST without correct syntax
- Using WHERE to limit rows
employees with columns id, name, and salary, what will this query return?SELECT name FROM employees ORDER BY salary DESC LIMIT 3;
Solution
Step 1: Understand ORDER BY salary DESC
This sorts employees by salary from highest to lowest.Step 2: Apply LIMIT 3
Limits the output to the top 3 rows after sorting.Final Answer:
The names of the 3 employees with the highest salaries. -> Option AQuick Check:
ORDER BY DESC + LIMIT 3 = top 3 highest [OK]
- Confusing DESC with ASC order
- Thinking LIMIT applies before sorting
- Believing LIMIT causes syntax error with ORDER BY
SELECT * FROM sales WHERE amount > 100 LIMIT 10 OFFSET 5;
What is the most likely reason?
Solution
Step 1: Check syntax of LIMIT and OFFSET
PostgreSQL supports LIMIT and OFFSET in any case and syntax is correct.Step 2: Understand WHERE clause effect
WHERE amount > 100 filters rows; if many match, LIMIT 10 OFFSET 5 returns 10 rows after skipping 5.Final Answer:
The query is correct; it returns only 10 rows after skipping 5. -> Option AQuick Check:
LIMIT + OFFSET works as expected in PostgreSQL [OK]
- Thinking OFFSET is unsupported
- Believing case sensitivity matters for keywords
- Assuming WHERE is ignored
employees(department, name, salary). Which approach best controls the result to achieve this?Solution
Step 1: Understand the need for top N per group
We want top 3 salaries per department, not overall top 3.Step 2: Identify correct SQL technique
Window functions with ROW_NUMBER() partitioned by department rank salaries per group.Step 3: Filter rows with row number ≤ 3
This returns top 3 employees per department correctly.Final Answer:
Use a window function with ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) and filter rows where row number ≤ 3. -> Option BQuick Check:
Window functions + filtering = top N per group [OK]
- Using LIMIT without partitioning
- Using GROUP BY without ranking
- Confusing GROUP BY columns
Ready to prove it?
Pass the test and this pattern moves unknown
