| From: | Tender Wang <tndrwang(at)gmail(dot)com> |
|---|---|
| To: | idrissaajalloh(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19861: Self-join elimination drops a VOLATILE predicate and changes the query result |
| Date: | 2026-11-11 02:23:58 |
| Message-ID: | CAHewXNmPG1M3AYiHuPevBH2zvxPy7oJUcaw_pw_nK1dhMcqHtw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
PG Bug reporting form <noreply(at)postgresql(dot)org> 于2026年11月11日周三 09:54写道:
>
> This occurs when self-join elimination is enabled for a primary-key
> self-join with alias-specific calls to the same VOLATILE predicate.
>
After one relation is removed, SJE rewrites its Vars to reference the
remaining relation.
In this case, that turns
is_odd_call(a.id)
is_odd_call(b.id)
into two structurally identical expressions referencing the same relation.
fixup_selfjoin_quals() then treats the second expression as a
duplicate and removes it.
That is not valid for volatile expressions, since the two occurrences
represent separately observable evaluations.
The attached patch conservatively disables SJE when the query jointree
contains volatile functions.
We could try to preserve volatile clauses while continuing to
eliminate the self-join.
However, SJE can both rewrite and relocate jointree quals, so avoiding
duplicate removal alone may not be sufficient to preserve the number
and timing of volatile evaluations.
Handling all such cases precisely would add a fair amount of
complexity for a rather uncommon optimization opportunity.
Since SJE is only an optimization, I do not think that complexity is
justified here.
Skipping SJE for queries with volatile jointree quals gives us a
simple correctness boundary, although it is admittedly conservative.
Any thoughts?
--
Thanks,
Tender Wang
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Skip-SJE-if-jointree-containing-VOLATILE-function.patch | text/plain | 3.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Corey Huinker | 2026-11-11 01:54:33 | Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti |