postgres.git / summary / log / commit / refs
commit f19502f04edc97f124db39faa388c9b54b7383cf
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Nov 27 18:09:59 2025 +0000
First released in: 14.21, 15.16, 16.12, 17.8, 18.2
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or any !amoptionalkey index), this
could result in dropping all available quals for the index's first
key, preventing us from generating an indexscan.
It's fair to question the practical usefulness of this case. Since
hash only supports equality quals, the situation could only arise
if the index's predicate is "WHERE indexkey = constant", implying
that the index contains only one hash value, which would make hash
a really poor choice of index type. However, perhaps there are
other !amoptionalkey index AMs out there with which such cases are
more plausible.
To fix, just don't filter the candidate indexquals this way if
the index is !amoptionalkey. That's a bit hokey because it may
result in testing quals we didn't need to test, but to do it
more accurately we'd have to redundantly identify which candidate
quals are actually usable with the index, something we don't know
at this early stage of planning. Doesn't seem worth the effort.
Reported-by: Sergei Glukhov <s.glukhov@postgrespro.ru>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/e200bf38-6b45-446a-83fd-48617211feff@postgrespro.ru
Backpatch-through: 14
src/backend/optimizer/path/indxpath.c | 10 ++++++++++
src/test/regress/expected/hash_index.out | 21 +++++++++++++++++++++
src/test/regress/sql/hash_index.sql | 13 +++++++++++++
3 files changed, 44 insertions(+)
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index 3800f0cdfb7..a50a0a386db 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -3412,6 +3412,16 @@ check_index_predicates(PlannerInfo *root, RelOptInfo *rel)
if (is_target_rel)
continue;
+ /*
+ * If index is !amoptionalkey, also leave indrestrictinfo as set
+ * above. Otherwise we risk removing all quals for the first index
+ * key and then not being able to generate an indexscan at all. It
+ * would be better to be more selective, but we've not yet identified
+ * which if any of the quals match the first index key.
+ */
+ if (!index->amoptionalkey)
+ continue;
+
/* Else compute indrestrictinfo as the non-implied quals */
index->indrestrictinfo = NIL;
foreach(lcr, rel->baserestrictinfo)
diff --git a/src/test/regress/expected/hash_index.out b/src/test/regress/expected/hash_index.out
index a2036a15972..2003b46e39e 100644
--- a/src/test/regress/expected/hash_index.out
+++ b/src/test/regress/expected/hash_index.out
@@ -40,6 +40,8 @@ CREATE INDEX hash_name_index ON hash_name_heap USING hash (random name_ops);
CREATE INDEX hash_txt_index ON hash_txt_heap USING hash (random text_ops);
CREATE INDEX hash_f8_index ON hash_f8_heap USING hash (random float8_ops)
WITH (fillfactor=60);
+CREATE INDEX hash_i4_partial_index ON hash_i4_heap USING hash (seqno)
+ WHERE seqno = 9999;
--
-- Also try building functional, expressional, and partial indexes on
-- tables that already contain data.
@@ -131,6 +133,25 @@ SELECT * FROM hash_f8_heap
-------+--------
(0 rows)
+--
+-- partial hash index
+--
+EXPLAIN (COSTS OFF)
+SELECT * FROM hash_i4_heap
+ WHERE seqno = 9999;
+ QUERY PLAN
+--------------------------------------------------------
+ Index Scan using hash_i4_partial_index on hash_i4_heap
+ Index Cond: (seqno = 9999)
+(2 rows)
+
+SELECT * FROM hash_i4_heap
+ WHERE seqno = 9999;
+ seqno | random
+-------+------------
+ 9999 | 1227676208
+(1 row)
+
--
-- hash index
-- grep '^90[^0-9]' hashovfl.data
diff --git a/src/test/regress/sql/hash_index.sql b/src/test/regress/sql/hash_index.sql
index 527024f7109..72696f27b6e 100644
--- a/src/test/regress/sql/hash_index.sql
+++ b/src/test/regress/sql/hash_index.sql
@@ -53,6 +53,9 @@ CREATE INDEX hash_txt_index ON hash_txt_heap USING hash (random text_ops);
CREATE INDEX hash_f8_index ON hash_f8_heap USING hash (random float8_ops)
WITH (fillfactor=60);
+CREATE INDEX hash_i4_partial_index ON hash_i4_heap USING hash (seqno)
+ WHERE seqno = 9999;
+
--
-- Also try building functional, expressional, and partial indexes on
-- tables that already contain data.
@@ -117,6 +120,16 @@ SELECT * FROM hash_f8_heap
SELECT * FROM hash_f8_heap
WHERE hash_f8_heap.random = '88888888'::float8;
+--
+-- partial hash index
+--
+EXPLAIN (COSTS OFF)
+SELECT * FROM hash_i4_heap
+ WHERE seqno = 9999;
+
+SELECT * FROM hash_i4_heap
+ WHERE seqno = 9999;
+
--
-- hash index
-- grep '^90[^0-9]' hashovfl.data
[parent: f9f928304bb7]