| From: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Redundant qualifier elimination |
| Date: | 2026-07-30 12:48:18 |
| Message-ID: | DKBX1KUW8KUW.2DU5RD192DHIQ@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Bug report #19572 [1] describes a case where the same qual appears in
both a JOIN's ON clause and the WHERE clause, causing the planner to
misestimate the row count and pick a worse plan (in the report, it
flipped JIT on). IIUC this is working as expected: the planner treats
each AND'ed clause as independent and multiplies their selectivities, so
an identical duplicate gets its selectivity squared.
I hadn't come across this myself, but the reporter mentioned it can show
up with ORM-generated SQL, which seems plausible. So I'm wondering
whether it's worth handling it in the planner.
I'm attaching a PoC that it drops a base-relation restriction clause
when an equal() clause is already present. Note the duplicate is only
visible after qual pushdown, the ON-clause copy only becomes a
baserestrictinfo once distributed, so the check lives in
add_base_clause_to_rel(), alongside the existing "skip always-true qual"
logic.
It only handles exactly identical quals. It could perhaps be generalized
to drop implied quals (if qual1 is true, qual2 is always true). I think
that predicate_implied_by() in predtest.c already does this kind of
proof, though today IIUC it's only used for partial indexes, partition
pruning and constraint exclusion, not the base qual list. I'm not sure
the general case is worth the added planning time.
Thoughts?
[1] https://www.postgresql.org/message-id/flat/19572-f770e89412629023%40postgresql.org
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Prevent-duplicate-base-restriction-clauses-from-bein.patch | text/plain | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shlok Kyal | 2026-07-30 12:49:57 | Re: Support EXCEPT for ALL SEQUENCES publications |
| Previous Message | Shlok Kyal | 2026-07-30 12:47:33 | Re: Support EXCEPT for ALL SEQUENCES publications |