Hash index for equality in PostgreSQL - Step-by-Step Execution

Concept Flow - Hash index for equality

Query with equality condition

↓

Check if hash index exists on column

Yes↓

Compute hash of search value

↓

Use hash index to find matching rows

↓

Return rows matching equality condition

↓

End

When a query uses equality (=) on a column with a hash index, PostgreSQL computes the hash of the search value and uses the index to quickly find matching rows.

Execution Sample

PostgreSQL

CREATE INDEX idx_hash_name ON users USING hash (name);
SELECT * FROM users WHERE name = 'Alice';

Create a hash index on the 'name' column and query rows where name equals 'Alice'.

Execution Table

Step	Action	Input/Condition	Result/Output
1	Receive query	SELECT * FROM users WHERE name = 'Alice'	Start processing query
2	Check index type on 'name'	Hash index exists	Use hash index for lookup
3	Compute hash	Hash('Alice')	Hash value computed
4	Search hash index	Hash value	Find matching row pointers
5	Fetch rows	Row pointers from index	Retrieve rows where name = 'Alice'
6	Return result	Matching rows	Rows with name 'Alice' returned
7	End	No more steps	Query complete

💡 Query ends after returning all rows matching the equality condition using the hash index.

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
query	SELECT * FROM users WHERE name = 'Alice'	Same	Same	Same
hash_index_exists	Unknown	True	True	True
hash_value	None	Hash('Alice')	Hash('Alice')	Hash('Alice')
row_pointers	None	None	Found pointers	Found pointers
result_rows	None	None	None	Rows with name 'Alice'

Key Moments - 2 Insights

Why does PostgreSQL use a hash index only for equality conditions?

Because hash indexes store hash values that match exactly, they work efficiently only for equality (=) checks, not for range or inequality conditions. See execution_table step 2 and 3.

What happens if there is no hash index on the column?

PostgreSQL will not use a hash index and will perform a sequential scan or use another index type. This is implied in execution_table step 2 where the presence of the hash index is checked.

Visual Quiz - 3 Questions

Look at the execution_table, what is the hash value computed for?

A The entire row data

B The search value 'Alice'

C The table name

D The index name

💡 Hint

Refer to execution_table step 3 where hash is computed for 'Alice'

At which step does PostgreSQL fetch the actual rows from the table?

A Step 5

B Step 3

C Step 2

D Step 7

💡 Hint

Check execution_table step 5 where rows are retrieved using row pointers

If the query used a condition 'name LIKE 'Al%'' instead of equality, what would happen?

A Hash index would still be used

B Query would fail

C Hash index would not be used

D Hash index would be converted to B-tree

💡 Hint

Hash indexes only support equality, see key_moments explanation

Concept Snapshot

Hash index in PostgreSQL:
- Created with: CREATE INDEX idx ON table USING hash(column);
- Used only for equality (=) conditions
- Works by hashing the search value and quickly locating matching rows
- Not suitable for range or pattern searches
- Provides fast lookups when equality condition matches

Full Transcript

This visual execution trace shows how PostgreSQL uses a hash index for queries with equality conditions. First, the query is received and PostgreSQL checks if a hash index exists on the searched column. If yes, it computes the hash of the search value. Then it uses the hash index to find pointers to matching rows. Finally, it fetches and returns the rows where the column equals the search value. Hash indexes only work efficiently for equality conditions, not for ranges or patterns. If no hash index exists, PostgreSQL uses other methods like sequential scans or different indexes.

Practice

1.

What is the main advantage of using a hash index in PostgreSQL?

easy

A. It speeds up equality searches on a column.

B. It improves performance of range queries.

C. It compresses data to save disk space.

D. It automatically updates foreign keys.

Solution

1. Step 1: Understand hash index purpose

   Hash indexes are designed to speed up searches where you look for exact matches (equality) on a column.

2. Step 2: Compare with other index types

   Unlike B-tree indexes, hash indexes do not support range queries or ordering, so they are not useful for those.

3. Final Answer:

   It speeds up equality searches on a column. -> Option A

4. Quick Check:

   Hash index = equality speedup [OK]

Hint: Hash indexes are for exact matches, not ranges. [OK]

Common Mistakes:

• Thinking hash indexes speed up range queries
• Confusing hash indexes with data compression
• Assuming hash indexes handle foreign keys automatically

2.

Which of the following is the correct syntax to create a hash index on the email column of a table named users?

?

easy

A. CREATE INDEX ON users HASH (email);

B. CREATE HASH INDEX users_email ON users (email);

C. CREATE INDEX users_email ON users USING btree (email);

D. CREATE INDEX users_email_hash ON users USING hash (email);

Solution

1. Step 1: Recall hash index syntax

   The correct syntax uses CREATE INDEX, specifies the index name, the table, and uses USING hash to indicate a hash index.

2. Step 2: Check each option

   CREATE INDEX users_email_hash ON users USING hash (email); matches the correct syntax exactly. The other options have syntax errors or use the wrong index type.

3. Final Answer:

   CREATE INDEX users_email_hash ON users USING hash (email); -> Option D

4. Quick Check:

   CREATE INDEX ... USING hash ... [OK]

Hint: Use 'CREATE INDEX name ON table USING hash (column);' [OK]

Common Mistakes:

• Using CREATE HASH INDEX instead of CREATE INDEX
• Forgetting 'USING hash' clause
• Using btree instead of hash for hash index

3.

Given the table products(id INT, name TEXT) with a hash index on id, what will the query SELECT * FROM products WHERE id = 10; most likely use?

medium

A. A sequential scan ignoring the index

B. A hash index scan for fast equality lookup

C. A bitmap index scan for range search

D. A full table lock before scanning

Solution

1. Step 1: Identify query condition type

   The query uses an equality condition on the id column: id = 10.

2. Step 2: Match index type to query

   Since there is a hash index on id, PostgreSQL will use a hash index scan to quickly find rows where id equals 10.

3. Final Answer:

   A hash index scan for fast equality lookup -> Option B

4. Quick Check:

   Equality query + hash index = hash index scan [OK]

Hint: Equality WHERE uses hash index scan if available. [OK]

Common Mistakes:

• Assuming sequential scan always happens
• Confusing bitmap index with hash index
• Thinking hash index supports range queries

4.

Consider the following SQL commands:
CREATE TABLE employees(id INT, name TEXT);
CREATE INDEX emp_id_hash ON employees USING hash (id);
SELECT * FROM employees WHERE id > 5;
What is the problem with using the hash index in this query?

medium

A. The table must have a primary key before creating a hash index.

B. The index name is invalid for hash indexes.

C. Hash indexes do not support range queries like id > 5.

D. The query syntax is incorrect for using indexes.

Solution

1. Step 1: Understand hash index limitations

   Hash indexes only support equality searches, not range conditions like id > 5.

2. Step 2: Analyze the query condition

   The query uses a range condition, so the hash index cannot be used efficiently here.

3. Final Answer:

   Hash indexes do not support range queries like id > 5. -> Option C

4. Quick Check:

   Range query + hash index = no use [OK]

Hint: Hash indexes only work with '=' conditions. [OK]

Common Mistakes:

• Thinking hash indexes support range queries
• Believing index names must follow special rules
• Assuming primary key is required for hash index

5.

You have a large table orders(order_id INT, customer_id INT, status TEXT). You often query orders by customer_id with equality conditions, but sometimes you query by status with range-like conditions (e.g., status > 'A'). Which indexing strategy is best?

hard

A. Create a hash index on customer_id and a B-tree index on status.

B. Create hash indexes on both customer_id and status.

C. Create a B-tree index on customer_id only.

D. Create no indexes to avoid overhead.

Solution

1. Step 1: Match index types to query patterns

   Hash indexes are good for equality searches, so use one on customer_id. B-tree indexes support range queries, so use one on status.

2. Step 2: Evaluate options

   Create a hash index on customer_id and a B-tree index on status. correctly assigns hash index for equality and B-tree for range. Create hash indexes on both customer_id and status. wrongly uses hash for range. Create a B-tree index on customer_id only. misses index on status. Create no indexes to avoid overhead. ignores performance.

3. Final Answer:

   Create a hash index on customer_id and a B-tree index on status. -> Option A

4. Quick Check:

   Equality = hash, range = B-tree [OK]

Hint: Use hash for '=' and B-tree for ranges together. [OK]

Common Mistakes:

• Using hash index for range queries
• Not indexing frequently queried columns
• Avoiding indexes due to overhead without reason