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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tender Wang <tndrwang(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Reduce "Var IS [NOT] NULL" quals during constant folding
Date: 2025-08-19 17:38:49
Message-ID: aKS2qVOT0oE59MXd@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(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.
>
> [...]
>
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-08-19 17:40:50 Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Previous Message Daniil Davydov 2025-08-19 17:37:54 Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue