Horton

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

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Richard Guo <guofenglinux@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-21T17:49:30Z
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 Fri, Mar 21, 2025 at 10:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
> > However, I'm a bit concerned about the overall premise of the patch
> > set. It feels like it is moving something that really ought to happen
> > at optimization time back to parse time. I have a feeling that's going
> > to break something, although I am not sure right now exactly what.
>
> Ugh, no, that is *completely* unworkable.  Suppose that the user
> does CREATE VIEW, and the parse tree recorded for that claims that
> column X is not-nullable.  Then the user drops the not-null
> constraint, and then asks to execute the view.  We'll optimize on
> the basis of stale information.
>
> The way to make this work is what I said before: move the planner's
> collection of relation information to somewhere a bit earlier in
> the planner.  But not to outside the planner.
>

Reading this reminded me of the existing issue in [1] where we've broken
session isolation of temporary relation data.  There it feels like we are
making decisions in the parser that really belong in the planner since
catalog data is needed to determine relpersistence in many cases.  If we
are looking for a spot "earlier in the planner" to attach relation
information, figuring out how to use that to improve matters related to
relpersistence seems warranted.

David J.

[1]
https://www.postgresql.org/message-id/4xxau766dofbwugeyvjftra3g5f7ifaal2clgrbpr7jqotr4av%40d3ige2krpoza