Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

> On Wed, Jul 07, 2021 at 01:20:24PM +1200, David Rowley wrote:
> On Wed, 7 Jul 2021 at 13:04, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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.

Hi,

This patch still occupies some place in my head, so I would like to ask few
questions to see where it's going:

* From the last emails in this thread I gather that the main obstacle from the
design side of things is functionality around figuring out if a Var could be
NULL or not, and everyone is waiting for a counterproposal about how to do
that better. Is that correct?

* Is this thread only about notnullattrs field in RelOptInfo, or about the
UniqueKeys patch series after all? The title indicates the first one, but the
last posted patch series included everything as far as I can see.

* Putting my archaeologist's hat on, I've tried to find out what this
alternative proposal was about. The result findings are scattered through the
archives -- which proves that it's a hard topic indeed -- and participants of
this thread are probably more aware about them than I am. The most detailed
handwaving I found in the thread [1], with an idea to introduce NullableVar
wrapper created by parser, is that it? It makes more clear why such approach
could be more beneficial than a new field in RelOptInfo. And if the thread is
only about the notnullattrs, I guess it would be indeed enough to object.

* Now, how essential is notnullattrs functionality for the UniqueKeys patch
series? From what I understand, it's being used to set multi_nulls field of
every UniqueKey to indicate whether this key could produce NULL or not (which
means no guaranties about uniqueness could be provided). Is there a way to
limit the scope of the patch series and introduce UniqueKeys without require
multi_nulls at all, or (again, in some limited situations) fetch necessary
information somehow on the fly e.g. only from catcache without introducing
any new infrastructure?

[1]: https://www.postgresql.org/message-id/25142.1580847861%40sss.pgh.pa.us