Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series) - Mailing list pgsql-hackers

From David Rowley
Subject Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Date
Msg-id CAApHDvo5b2pYX+dbPy+ysGBSarezRSfXthX32TZNFm0wPdfKGQ@mail.gmail.com
Whole thread Raw
In response to Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)  (Andy Fan <zhihui.fan1213@gmail.com>)
Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
On Wed, 7 Jul 2021 at 13:04, Andy Fan <zhihui.fan1213@gmail.com> wrote:
> Looking forward to watching this change closely, thank you both David and Tom!
> But I still don't understand what the faults my way have , do you mind telling the
> details?

The problem is that we don't need 6 different ways to determine if a
Var can be NULL or not.  You're proposing to add a method using
Bitmapsets and Tom has some proposing ideas around tracking
nullability in Vars.  We don't need both.

It seems to me that having it in Var allows us to have a much finer
gradient about where exactly a Var can be NULL.

For example: SELECT nullablecol FROM tab WHERE nullablecol = <value>;

If the equality operator is strict then the nullablecol can be NULL in
the WHERE clause but not in the SELECT list. Tom's idea should allow
us to determine both of those things but your idea cannot tell them
apart, so, in theory at least, Tom's idea seems better to me.

David



pgsql-hackers by date:

Previous
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: [HACKERS] logical decoding of two-phase transactions
Next
From: Bruce Momjian
Date:
Subject: Re: visibility map corruption