Re: Reduce "Var IS [NOT] NULL" quals during constant folding - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Reduce "Var IS [NOT] NULL" quals during constant folding
Date
Msg-id aKS2qVOT0oE59MXd@nathan
Whole thread Raw
In response to Re: Reduce "Var IS [NOT] NULL" quals during constant folding  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Reduce "Var IS [NOT] NULL" quals during constant folding
List pgsql-hackers
On Wed, Jul 30, 2025 at 03:17:38PM +0900, Richard Guo wrote:
> On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra <tomas@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.
> 
> [...]
> 
> 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.)

There is still an open item for this one, but it's not clear whether we are
planning to do anything about this for v18, especially since nobody has
shown measurable performance impact.  Does anyone want to argue for
addressing this for v18, or shall we close the open item as "Won't Fix"?

-- 
nathan



pgsql-hackers by date:

Previous
From: Daniil Davydov
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Next
From: Masahiko Sawada
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue