]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Allow indexscans on partial hash indexes with implied quals.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Nov 2025 18:09:59 +0000 (13:09 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Nov 2025 18:09:59 +0000 (13:09 -0500)
commita212877dc7293cb05cf8f635f438f38e9161265e
treef639f70866eea7fb8290942779e554e55fb2bf4a
parent9ad15f404a70114658290d4ace3b9b9d924a209b
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
src/test/regress/expected/hash_index.out
src/test/regress/sql/hash_index.sql