Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Tender Wang <tndrwang@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-10T20:07:25Z
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 Thu, Apr 10, 2025 at 3:54 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > A related point that I'm noticing is that you record the not-NULL
> > information in the RangeTblEntry.
>
> Did we not just complain about that w.r.t. the v1 version of this
> patch?  RangeTblEntry is not where to store this info.  We need
> a new data structure, and IMO the data structure should be a hashtable
> based on table OID, not relid.  That way we can amortize across
> multiple references to the same table within a query.

It's not quite the same complaint, because the earlier complaint was
that it was actually being done at parse time, and this complaint is
that it is scribbling on a parse-time data structure.

-- 
Robert Haas
EDB: http://www.enterprisedb.com