Hash index for equality in PostgreSQL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a hash index in PostgreSQL?

A hash index is a type of database index that uses a hash function to map keys to a location. It is optimized for fast equality comparisons, meaning it quickly finds rows where a column equals a specific value.

beginner

When should you use a hash index in PostgreSQL?

Use a hash index when you need very fast lookups for equality comparisons (e.g., WHERE column = value). It is not suitable for range queries or sorting.

beginner

How do you create a hash index on a column named 'username' in PostgreSQL?

You use the command:
CREATE INDEX idx_username_hash ON tablename USING hash (username);
This creates a hash index on the 'username' column.

intermediate

What is a limitation of hash indexes in PostgreSQL compared to B-tree indexes?

Hash indexes only support equality comparisons and cannot be used for range queries or sorting. Also, before PostgreSQL 10, hash indexes were not WAL-logged, so they were not crash-safe.

beginner

How does PostgreSQL use a hash index during a query?

When a query has a condition like WHERE column = value, PostgreSQL can use the hash index to quickly find the matching rows by hashing the value and looking up the location directly.

What type of queries are hash indexes in PostgreSQL best suited for?

A Range queries (e.g., WHERE column > value)

B Full text search

C Sorting results

D Equality comparisons (e.g., WHERE column = value)

Hash indexes are optimized for equality comparisons only, not for range queries or sorting.

Which command creates a hash index on the 'email' column of a table named 'users'?

A CREATE INDEX idx_email_hash ON users USING btree (email);

B CREATE INDEX idx_email_hash ON users USING hash (email);

C CREATE INDEX idx_email_hash ON users (email);

D CREATE HASH INDEX idx_email ON users (email);

The correct syntax uses 'CREATE INDEX' with 'USING hash' to specify a hash index.

Before PostgreSQL 10, what was a major drawback of hash indexes?

A They were not crash-safe because they were not WAL-logged

B They could not be created on text columns

C They were slower than sequential scans

D They supported only range queries

Before version 10, hash indexes were not WAL-logged, so they could be lost after a crash.

Can a hash index be used to speed up queries with 'WHERE column > value'?

A No, hash indexes only support equality comparisons

B Yes, hash indexes support all comparison operators

C Yes, but only if combined with a B-tree index

D No, but they support sorting

Hash indexes only work for equality comparisons, not for range queries like greater than.

Which of the following is true about hash indexes in PostgreSQL?

A They support full text search

B They are the default index type

C They use a hash function to map keys to locations

D They automatically maintain sorted order

Hash indexes use a hash function to quickly find matching keys but do not maintain sorted order.

Explain what a hash index is and when you would use it in PostgreSQL.

Think about how hash indexes help find exact matches quickly.

Describe the limitations of hash indexes compared to B-tree indexes in PostgreSQL.

Consider what queries hash indexes cannot optimize.

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