pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Allow indexscans on partial hash indexes with implied quals. 6+ messages / 1 participants [nested] [flat]
* pgsql: Allow indexscans on partial hash indexes with implied quals. @ 2025-11-27 18:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-11-27 18:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5528e8d1046062698b7db179e4280817eaeb5f30 Modified Files -------------- 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(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Allow indexscans on partial hash indexes with implied quals. @ 2025-11-27 18:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-11-27 18:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a212877dc7293cb05cf8f635f438f38e9161265e Modified Files -------------- 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(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Allow indexscans on partial hash indexes with implied quals. @ 2025-11-27 18:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-11-27 18:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e79b2766216ab998080725323bcb4f4e87d639cc Modified Files -------------- 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(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Allow indexscans on partial hash indexes with implied quals. @ 2025-11-27 18:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-11-27 18:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b497766a8e638f48a71fedfe9b4019d5a7fde6bf Modified Files -------------- 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(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Allow indexscans on partial hash indexes with implied quals. @ 2025-11-27 18:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-11-27 18:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f19502f04edc97f124db39faa388c9b54b7383cf Modified Files -------------- 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(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Allow indexscans on partial hash indexes with implied quals. @ 2025-11-27 18:10 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-11-27 18:10 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9e77323fccff6a084115cde3641dbcee86624f14 Modified Files -------------- src/backend/optimizer/path/indxpath.c | 10 ++++++++++ src/test/regress/expected/create_index.out | 2 ++ src/test/regress/expected/hash_index.out | 19 +++++++++++++++++++ src/test/regress/sql/create_index.sql | 3 +++ src/test/regress/sql/hash_index.sql | 10 ++++++++++ 5 files changed, 44 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-11-27 18:10 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-27 18:10 pgsql: Allow indexscans on partial hash indexes with implied quals. Tom Lane <tgl@sss.pgh.pa.us> 2025-11-27 18:10 pgsql: Allow indexscans on partial hash indexes with implied quals. Tom Lane <tgl@sss.pgh.pa.us> 2025-11-27 18:10 pgsql: Allow indexscans on partial hash indexes with implied quals. Tom Lane <tgl@sss.pgh.pa.us> 2025-11-27 18:10 pgsql: Allow indexscans on partial hash indexes with implied quals. Tom Lane <tgl@sss.pgh.pa.us> 2025-11-27 18:10 pgsql: Allow indexscans on partial hash indexes with implied quals. Tom Lane <tgl@sss.pgh.pa.us> 2025-11-27 18:10 pgsql: Allow indexscans on partial hash indexes with implied quals. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox