Horton

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

Tender Wang <tndrwang@gmail.com>

View thread
From: Tender Wang <tndrwang@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-26T06:06:11Z
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

Richard Guo <guofenglinux@gmail.com> 于2025年3月26日周三 10:16写道：

> On Sun, Mar 23, 2025 at 6:25 PM Richard Guo <guofenglinux@gmail.com>
> wrote:
> > On Sat, Mar 22, 2025 at 2:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > 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.
>
> > I'm considering moving the collection of attnotnull information before
> > pull_up_sublinks, in hopes of leveraging this info to pull up NOT IN
> > in the future, something like attached.
>
> Here is an updated version of the patch with some cosmetic changes and
> a more readable commit message.  I'm wondering if it's good enough to
> be pushed.  Any comments?
>

The comment about  notnullattnums in struct RangeTblEntry says that:
* notnullattnums is zero-based set containing attnums of NOT NULL
* columns.

But in get_relation_notnullatts():
rte->notnullattnums = bms_add_member(rte->notnullattnums,
                                                                    i + 1);

The notnullattnums seem to be 1-based.


-- 
Thanks,
Tender Wang