On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra <to...@vondra.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
