On Thu, May 14, 2020 at 6:20 AM David Rowley <dgrowle...@gmail.com> wrote:
> On Thu, 14 May 2020 at 03:48, Andy Fan <zhihui.fan1...@gmail.com> wrote: > > On Wed, May 13, 2020 at 8:04 PM Ashutosh Bapat < > ashutosh.bapat....@gmail.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
