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.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.

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