From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tender Wang <tndrwang(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Anti join confusion |
Date: | 2025-02-27 02:26:24 |
Message-ID: | 2323997.1740623184@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Thu, 27 Feb 2025 at 14:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But I think having NOT NULL info available earlier might allow
>> removal of some nasty kluges (I'm looking at you,
>> restriction_is_always_true).
> Can you elaborate on the gripe here, or point to the thread where you have?
The Right Way (TM) to do reduction of IS[NOT]NULL to const-true
or const-false is to do it during constant folding
(eval_const_expressions). Doing it later is a hack, because
(a) we can't do any further folding using the constant, and
(b) it introduces bugs, as per [1] (and IIRC that wasn't the
first problem we found with that code).
Right now we have to do it later because we haven't run any of the
plancat.c code at the point where we do eval_const_expressions.
But if we could decouple that and have the info available during
eval_const_expressions, it'd be way cleaner.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/f5320d3d-77af-4ce8-b9c3-4715ff33f213%40rentec.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-02-27 03:02:51 | Re: per backend WAL statistics |
Previous Message | Corey Huinker | 2025-02-27 02:19:12 | Re: Statistics Import and Export |