Common query optimization patterns in PostgreSQL - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When we write database queries, some ways of asking questions take longer than others.
We want to understand how the time to get answers grows as the data gets bigger.
Analyze the time complexity of this query pattern using indexes and joins.
SELECT orders.id, customers.name
FROM orders
JOIN customers ON orders.customer_id = customers.id
WHERE customers.region = 'North';
This query finds orders from customers in the 'North' region by joining two tables.
Look for repeated work done by the database engine.
- Primary operation: Scanning the customers table to find matching regions.
- How many times: Once for each row in orders, then matching customers for each found order.
As the number of customers and orders grows, the work increases.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 customers, 50 orders | About 50 checks + matching customers |
| 100 customers, 500 orders | About 500 checks + matching customers |
| 1000 customers, 5000 orders | About 5000 checks + matching customers |
Pattern observation: The work grows roughly in proportion to the number of customers and orders.
Time Complexity: O(n + m)
This means the time grows roughly with the size of both tables involved.
[X] Wrong: "Adding an index always makes the query instant."
[OK] Correct: Indexes help, but if the query scans many rows or joins large tables, it still takes time.
Understanding how queries grow with data size helps you write better questions and explain your choices clearly.
"What if we added a filter on orders before the join? How would that change the time complexity?"
Practice
Solution
Step 1: Understand what an index does
An index helps the database find rows faster by creating a quick lookup structure.Step 2: Match the purpose to the options
Only speeding up searches matches the purpose of an index; other options are unrelated.Final Answer:
To speed up searches on that column -> Option AQuick Check:
Index = Speed up search [OK]
- Thinking indexes reduce database size
- Confusing indexes with backups
- Assuming indexes encrypt data
Solution
Step 1: Recall the command to view query plans
PostgreSQL uses EXPLAIN to show how it will run a query.Step 2: Compare options to the correct command
Only EXPLAIN SELECT * FROM users; is valid syntax for query plans.Final Answer:
EXPLAIN SELECT * FROM users; -> Option AQuick Check:
EXPLAIN = Query plan check [OK]
- Using SHOW PLAN which is invalid
- Trying PLAN or DESCRIBE which are not PostgreSQL commands
- Missing the EXPLAIN keyword
SELECT id, name FROM employees WHERE department = 'Sales';Which optimization pattern does this query follow?
Solution
Step 1: Analyze the SELECT clause
The query selects only 'id' and 'name', not all columns with '*'.Step 2: Identify the optimization pattern
Selecting only needed columns reduces data transfer and improves speed.Final Answer:
Selecting only needed columns instead of * -> Option DQuick Check:
Selective columns = Better performance [OK]
- Confusing JOIN usage with column selection
- Thinking ORDER BY is always an optimization
- Assuming subqueries are used here
SELECT * FROM orders WHERE order_date = '2023-01-01';It runs slowly. Which fix will likely improve performance?
Solution
Step 1: Identify the cause of slowness
Query filters on order_date but may scan all rows without an index.Step 2: Apply optimization by indexing
Adding an index on order_date lets PostgreSQL find matching rows faster.Final Answer:
Add an index on the order_date column -> Option BQuick Check:
Index on filter column = Faster query [OK]
- Removing WHERE loses filtering purpose
- Changing SELECT * to COUNT(*) changes result, not speed
- Using GROUP BY without aggregation is incorrect
Solution
Step 1: Identify key optimization needs
Joining large tables and filtering by date needs indexes on join and filter columns.Step 2: Use EXPLAIN to verify query plan
Checking the plan helps confirm indexes are used and query is efficient.Final Answer:
Create indexes on join columns and filter columns; use EXPLAIN to check plan -> Option CQuick Check:
Indexes + EXPLAIN = Best optimization [OK]
- Selecting all columns wastes resources
- Avoiding indexes slows queries
- Removing WHERE loses filtering benefits
