Why indexing strategy matters in PostgreSQL - Performance Analysis
Start learning this pattern below
Jump into concepts and practice - no test required
When we use indexes in a database, it changes how fast queries run.
We want to see how the choice of indexing affects the time a query takes as data grows.
Analyze the time complexity of the following query using an index.
SELECT * FROM employees
WHERE department_id = 5;
This query finds all employees in one department using an index on department_id.
Look at what repeats when the query runs.
- Primary operation: Searching the index tree to find matching rows.
- How many times: The search goes down the index levels, which is a few steps regardless of total rows.
As the table grows, the index search stays quick, but scanning all rows without an index gets slower.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 3 steps in index + few rows |
| 100 | About 4 steps in index + few rows |
| 1000 | About 5 steps in index + few rows |
Pattern observation: The index search grows very slowly, much better than checking every row.
Time Complexity: O(log n + k)
This means the search time grows slowly with data size, plus time to return matching rows.
[X] Wrong: "Adding an index always makes queries instantly fast regardless of data or query."
[OK] Correct: Some queries don't use indexes well, and indexes add overhead when writing data.
Understanding how indexes affect query speed shows you know how databases handle data efficiently.
What if we changed the index to cover multiple columns? How would the time complexity change?
Practice
Solution
Step 1: Understand what indexes do
Indexes act like shortcuts to quickly locate data without scanning the whole table.Step 2: Connect indexing to query speed
Good indexes reduce the time to find data, making queries faster and more efficient.Final Answer:
It helps the database find data faster, improving query speed. -> Option AQuick Check:
Index = Faster data search [OK]
- Thinking indexes slow down queries
- Believing indexes fix data errors
- Assuming indexes increase query ignoring
email in PostgreSQL?Solution
Step 1: Recall PostgreSQL index creation syntax
The correct syntax starts with CREATE INDEX, followed by index name, ON table name, and column list in parentheses.Step 2: Match syntax to options
CREATE INDEX idx_email ON users (email); matches the correct syntax exactly; others have wrong keywords or missing parentheses.Final Answer:
CREATE INDEX idx_email ON users (email); -> Option BQuick Check:
CREATE INDEX ... ON table (column) [OK]
- Omitting parentheses around column name
- Using wrong keywords like MAKE or INDEX CREATE
- Missing ON keyword before table name
orders with 1 million rows and an index on customer_id, what is the likely result of this query?SELECT * FROM orders WHERE customer_id = 12345;
Solution
Step 1: Understand index usage in queries
When a column is indexed, PostgreSQL uses the index to find matching rows quickly instead of scanning the whole table.Step 2: Apply to the given query
The query filters by customer_id, which is indexed, so the index helps find rows efficiently.Final Answer:
The query will use the index to quickly find matching rows. -> Option DQuick Check:
Indexed column = faster search [OK]
- Thinking index is ignored automatically
- Assuming query fails without explicit index hint
- Believing indexes filter out rows
Solution
Step 1: Understand index impact on data modification
Indexes must be updated every time data changes, so more indexes mean more work during INSERT, UPDATE, DELETE.Step 2: Connect to slower INSERT queries
Because indexes update on each insert, having many indexes slows down insert speed.Final Answer:
Indexes slow down data changes because they must update on each insert. -> Option AQuick Check:
More indexes = slower inserts [OK]
- Thinking indexes cause syntax errors
- Believing indexes block inserts
- Assuming indexes delete data automatically
products with columns id, category, and price. You often run this query:SELECT * FROM products WHERE category = 'books' AND price < 20;Which indexing strategy will most improve query speed without slowing inserts too much?
Solution
Step 1: Analyze query filter conditions
The query filters on both category and price together, so a composite index on both columns helps the database find matching rows efficiently.Step 2: Compare indexing options
Separate indexes may be less efficient because PostgreSQL might not combine them well; no index slows queries; indexing only price misses category filtering.Final Answer:
Create a composite index on (category, price). -> Option CQuick Check:
Composite index matches multi-column filters [OK]
- Creating separate indexes expecting same speed
- Indexing only one column in multi-filter queries
- Avoiding indexes to keep inserts fast but hurting queries
