Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Thu, May 14, 2020 at 6:20 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Thu, 14 May 2020 at 03:48, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> > On Wed, May 13, 2020 at 8:04 PM Ashutosh Bapat <
> ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> >> My impression about the one row stuff, is that there is too much
> >> special casing around it. We should somehow structure the UniqueKey
> >> data so that one row unique keys come naturally rather than special
> >> cased. E.g every column in such a case is unique in the result so
> >> create as many UniqueKeys are the number of columns
> >
> >
> > This is the beginning state of the UniqueKey, later David suggested
> > this as an optimization[1], I buy-in the idea and later I found it mean
> > more than the original one [2], so I think onerow is needed actually.
>
> Having the "onerow" flag was not how I intended it to work.
>
> Thanks for the detailed explanation. So I think we do need to handle
onerow
specially, (It means more things than adding each column as a UniqueKey).
but we don't need the onerow flag since we can tell it by ukey->exprs ==
NIL.

During the developer of this feature, I added some Asserts as double
checking
for onerow and exprs. it helps me to find some special cases. like
SELECT FROM multirows union SELECT FROM multirows; where targetlist is
NIL.
(I find the above case returns onerow as well just now). so onerow flag
allows us
check this special things with more attention. Even this is not the
original intention
but looks it is the one purpose now.

However I am feeling that removing onerow flag doesn't require much of code
changes. Almost all the special cases which are needed before are still
needed
after that and all the functions based on that like relation_is_onerow
/add_uniquekey_onerow is still valid, we just need change the
implementation.
so do you think we need to remove onerow flag totally?

Best Regards
Andy Fan