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

From Richard Guo
Subject Re: Reduce "Var IS [NOT] NULL" quals during constant folding
Date
Msg-id CAMbWs497DeTDspMzuu69g85uZtG3u8QJME+AWRcwrcUgS3m19Q@mail.gmail.com
Whole thread Raw
In response to Re: Reduce "Var IS [NOT] NULL" quals during constant folding  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Reduce "Var IS [NOT] NULL" quals during constant folding
List pgsql-hackers
On Wed, Aug 20, 2025 at 2:38 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> On Wed, Jul 30, 2025 at 03:17:38PM +0900, Richard Guo wrote:
> > 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"?

I don't think we're likely to do anything about this for v18.
Actually, I still doubt that the extra table_open call brings any
measurable performance impact, especially since the lock is already
held and the relation is likely already present in the relcache.

Also, I still don't think moving the expansion of virtual generated
columns to the rewriter (as Tom proposed) is a better idea.  It turned
out to have several problems that need to be fixed with the help of
PHVs, which is why we moved the expansion into the planner.

Thanks
Richard



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Raw parse tree is not dumped to log
Next
From: Chao Li
Date:
Subject: Re: Raw parse tree is not dumped to log