Horton

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

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, David Rowley <dgrowleyml@gmail.com>, Tender Wang <tndrwang@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-20T14:10:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix misuse of Relids for storing attribute numbers

  2. Reduce "Var IS [NOT] NULL" quals during constant folding

  3. Centralize collection of catalog info needed early in the planner

  4. Expand virtual generated columns before sublink pull-up

  5. Expand virtual generated columns in the planner

On Wed, Aug 20, 2025 at 10:29:03AM +0900, Richard Guo wrote:
> On Wed, Aug 20, 2025 at 2:38 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> 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.

Okay.  I have marked the v18 open item as "Won't Fix".

-- 
nathan