Covering indexes with INCLUDE in PostgreSQL - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
We want to understand how using covering indexes with INCLUDE affects query speed as data grows.
How does the query time change when the index holds extra columns to avoid looking up the main table?
Analyze the time complexity of this index and query.
CREATE INDEX idx_orders_customer_date ON orders (customer_id) INCLUDE (order_date);
SELECT order_date FROM orders WHERE customer_id = 123;
This creates an index on customer_id and stores order_date inside it to speed up queries that select order_date by customer_id.
Look at what repeats when the query runs.
- Primary operation: Searching the index tree for matching customer_id entries.
- How many times: Once per query, but may scan multiple matching entries depending on how many orders a customer has.
As the number of orders grows, the index helps find matching rows faster without scanning the whole table.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 3-4 steps to find matches |
| 100 | About 5-6 steps to find matches |
| 1000 | About 7-8 steps to find matches |
Pattern observation: The number of steps grows slowly, not directly with total rows, because the index tree is balanced.
Time Complexity: O(log n + k)
This means the query time grows slowly with total rows (log n) plus the number of matching rows (k) to read.
[X] Wrong: "Adding INCLUDE columns makes the index size and search time grow a lot."
[OK] Correct: INCLUDE columns add data only to leaf nodes, so the search steps stay about the same; it just avoids extra table lookups.
Understanding how covering indexes affect query speed shows you know how databases keep queries fast as data grows. This skill helps you design efficient data access.
What if we removed the INCLUDE clause and selected order_date in the query? How would the time complexity change?
Practice
INCLUDE in a PostgreSQL index?Solution
Step 1: Understand the role of INCLUDE in indexes
INCLUDE adds extra columns to the index that are not used for searching but can be returned in queries.Step 2: Identify the benefit of these extra columns
These extra columns help avoid reading the main table, speeding up SELECT queries that need those columns.Final Answer:
To add extra columns to the index for faster SELECT queries without searching on them -> Option DQuick Check:
INCLUDE adds columns for SELECT speed [OK]
- Thinking INCLUDE creates unique constraints
- Believing INCLUDE removes columns
- Assuming INCLUDE changes data types
users for column email and include last_login?Solution
Step 1: Recall the syntax for INCLUDE in PostgreSQL indexes
The correct syntax is to specify indexed columns first, then use INCLUDE for extra columns.Step 2: Match the syntax to the options
CREATE INDEX idx_email ON users(email) INCLUDE (last_login); correctly usesCREATE INDEX idx_email ON users(email) INCLUDE (last_login);Final Answer:
CREATE INDEX idx_email ON users(email) INCLUDE (last_login); -> Option AQuick Check:
Indexed columns first, INCLUDE for extras [OK]
- Putting all columns inside parentheses without INCLUDE
- Using WITH instead of INCLUDE
- Including columns in wrong order
CREATE INDEX idx_name ON employees(last_name) INCLUDE (first_name, department);, what will the query SELECT last_name, first_name FROM employees WHERE last_name = 'Smith'; most likely do?Solution
Step 1: Understand what INCLUDE columns do in the index
INCLUDE columns are stored in the index to avoid accessing the main table for those columns.Step 2: Analyze the query and index usage
The query filters on last_name (indexed) and selects first_name (included). The index covers both, so no table access needed.Final Answer:
Use the index to find rows and return both last_name and first_name without accessing the table -> Option BQuick Check:
INCLUDE columns avoid table access [OK]
- Assuming INCLUDE columns are not stored in the index
- Thinking table scan is always needed
- Confusing INCLUDE with indexed columns
CREATE INDEX idx_order ON orders(order_date) INCLUDE (customer_id; but get a syntax error. What is the problem?Solution
Step 1: Check the syntax of the CREATE INDEX statement
The statement has an opening parenthesis after INCLUDE but no closing parenthesis.Step 2: Identify the syntax error
Missing closing parenthesis causes the syntax error.Final Answer:
Missing closing parenthesis after customer_id -> Option CQuick Check:
Parentheses must be balanced [OK]
- Forgetting closing parenthesis
- Misordering columns
- Thinking INCLUDE needs multiple columns
SELECT product_id, price, stock FROM products WHERE product_id = 123; by creating a covering index. Which index is best?Solution
Step 1: Identify the filtering and selected columns in the query
The query filters on product_id and selects price and stock.Step 2: Choose an index that filters on product_id and includes price and stock
CREATE INDEX idx_product ON products(product_id) INCLUDE (price, stock); indexes product_id and includes price and stock, covering the query efficiently.Step 3: Compare other options
CREATE INDEX idx_product ON products(price, stock) INCLUDE (product_id); indexes price and stock, not filtering column; CREATE INDEX idx_product ON products(product_id, price, stock); indexes all columns but includes unnecessary columns in index key; CREATE INDEX idx_product ON products(product_id); lacks included columns, so table access needed.Final Answer:
CREATE INDEX idx_product ON products(product_id) INCLUDE (price, stock); -> Option AQuick Check:
Filter column indexed, others included [OK]
- Including filter columns instead of indexing them
- Indexing all columns as keys unnecessarily
- Not including selected columns causing table access
