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

Hi Dmitry:

On Wed, Nov 17, 2021 at 11:20 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > 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:

Thanks for that!

> * 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?

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

This thread is talking about the path series after all. Not null maintenance
is the first step of the UniqueKey patch.  If the not null issue can't
be addressed,
the overall UniqueKey patch would be hopeless.

> * 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?
>

_I_ think there is no way to bypass that.  I guess Tom has a bigger plan on
Var (not only for notnull), but no time to invest in them so far.  If
that is the case,
personally I think we can go ahead with my method first and continue the review
process.


-- 
Best Regards
Andy Fan