| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Tender Wang <tndrwang(at)gmail(dot)com> |
| Cc: | Nitin Motiani <nitinmotiani(at)google(dot)com>, leis(at)in(dot)tum(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: BUG #19765: Wrong result from a chain of LEFT JOINs since v16 |
| Date: | 2026-10-23 06:47:30 |
| Message-ID: | CAMbWs4-_jXZr7yGbuuf6myoSdXC-=d32MTZp2teNnkj9nP6L-A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Oct 23, 2026 at 12:42 PM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> I think the underlying issue is that the redundancy of such a clause
> is placement-dependent. Constant propagation itself is valid, but it
> does not imply that the original strict join clause can be discarded
> at every join level at which its clone might be applied.
Right, the clause is redundant at the directly formed t3/t4 join, and
whether it is redundant depends on where it gets applied.
However, your v3 adds a new field to RestrictInfo, which breaks ABI
and can't be back-patched.
IMO keeping a redundant clause costs little if we mark it as having
selectivity 1.0, and it's no worse than what v15 and earlier did,
which always kept such clauses. So I think we should accept some
redundant clauses in the bug fix. The placement-aware redundancy
checks can be a possible improvement for master.
- Richard
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2026-10-23 07:04:37 | Re: BUG #19761: btree_gist: "cannot subtract infinite dates" when inserting 'infinity' into a GiST index on date |
| Previous Message | Ayush Tiwari | 2026-10-23 05:59:43 | Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction |