Re: Reduce "Var IS [NOT] NULL" quals during constant folding

On 7/22/25 04:55, Richard Guo wrote:
> On Wed, Jul 16, 2025 at 10:57 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> On Wed, Jul 9, 2025 at 3:32 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>>> Here is a new rebase. I moved the call to preprocess_relation_rtes to
>>> a later point within convert_EXISTS_sublink_to_join, so we can avoid
>>> the work if it turns out that the EXISTS SubLink cannot be flattened.
>>> Nothing essential has changed.
>>>
>>> The NOT-IN pullup work depends on the changes in this patchset (it
>>> also relies on the not-null information), so I'd like to move it
>>> forward.
>>>
>>> Hi Tom, Robert -- just to be sure, are you planning to take another
>>> look at it?
>
>> I'm aiming to push this patchset next week, barring any objections.
>
> Hearing nothing, I've gone ahead and pushed the patchset. Thanks for
> all the reviews and discussion.
>

Hi Richard,

Does this mean we can close the PG18 open item tracking this?

* virtual generated columns and planning speed
Owner: Peter Eisentraut

If I understand correctly, the commits went only to master, which means
PG18 still does the table_open/table_close calls Tom complained about in
[1] and [2].

I think it'd be perfectly fine if it only affected cases with virtual
generated columns, but AFAICS we do the open/close call for every
relation. Has anyone tried to measure if the impact is measurable? I
suspect it's negligible, we already hold a lock on the rel anyway
(right?). But has anyone tried to measure if that's true?

If it turns out to be expensive, that might be an argument to backpatch
the changes after all - the commits seem fairly small/non-invasive.

regards

[1] https://www.postgresql.org/message-id/602561.1744314879%40sss.pgh.pa.us

[2] https://www.postgresql.org/message-id/1514756.1747925490%40sss.pgh.pa.us

--
Tomas Vondra