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

Junwang Zhao <zhjwpku@gmail.com>

From: Junwang Zhao <zhjwpku@gmail.com>

To: Richard Guo <guofenglinux@gmail.com>

Cc: Nathan Bossart <nathandbossart@gmail.com>, 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-09-07T11:11:52Z

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 →

Fix misuse of Relids for storing attribute numbers
- 2d756ebbe857 19 (unreleased) landed
Reduce "Var IS [NOT] NULL" quals during constant folding
- e2debb64380e 19 (unreleased) landed
Centralize collection of catalog info needed early in the planner
- 904f6a593a06 19 (unreleased) landed
Expand virtual generated columns before sublink pull-up
- e0d05295268e 19 (unreleased) landed
Expand virtual generated columns in the planner
- 1e4351af329f 18.0 cited

Attachments

v1-0001-use-Bitmapset-to-represent-not-null-attr-nums.patch (application/octet-stream) patch v1-0001

Hi,

On Thu, Aug 21, 2025 at 9:07 AM Richard Guo <guofenglinux@gmail.com> wrote:
>
> On Wed, Aug 20, 2025 at 11:11 PM Nathan Bossart
> <nathandbossart@gmail.com> wrote:
> > 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".
>
> Thank you for helping with this.
>
> Thanks
> Richard
>
>

While reading this thread, I found that it uses *Relids* to collect NOT NULL
attribute numbers, I think this might be an oversight, since ISTM that
Relids is used to represent the index of the relation in the range table.

I searched the code base and it seems nowhere to use Relids to represent
attribute numbers, and there is a *notnullattnums* field in RelOptInfo:

/* zero-based set containing attnums of NOT NULL columns */
Bitmapset *notnullattnums;

So I think it would be better to be consistent, anyway I post a trivial patch
if the community agrees with me.

-- 
Regards
Junwang Zhao