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

On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> 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].

You're right. This patchset is intended only for master, so it
doesn't address that open item for v18.

> 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?

I ran a naive test on v18: selecting from 10 tables, comparing the
unmodified v18 with a hacked version where the call to
expand_virtual_generated_columns() was removed, 3 times each. Here
are the planning times I observed.

create table t (a int, b int, c int);

explain (costs off)
select * from t t1
natural join t t2
natural join t t3
natural join t t4
natural join t t5
natural join t t6
natural join t t7
natural join t t8
natural join t t9
natural join t t10
;

-- unmodified v18
Time: 133.244 ms
Time: 132.831 ms
Time: 132.345 ms

-- the hacked version
Time: 132.756 ms
Time: 132.745 ms
Time: 133.728 ms

I didn't observe measurable impact, but perhaps others can run more
representative tests and demonstrate otherwise.

(I recall Peter E. mentioned he might run some tests to measure the
impact. Not sure if he's had the time to do that yet.)

> 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.

The main goal of this patchset is to collect NOT NULL information
early in the planning phase and use it to reduce NullTest quals during
constant folding.

It doesn't eliminate the added table_open call, but it does centralize
the collection of all required early-stage catalog information into a
single table_open/table_close call, which may help justify the added
overhead. However, I think Tom's proposal is to move the expansion
of virtual generated columns to the rewriter, so I'm not sure whether
backpatching this patchset to v18 would fully address his concerns.

(I had previously proposed including 0001 and 0002 in v18, but I
dropped the idea due to a lack of support.)

Thanks
Richard