Re: UniqueKey on Partitioned table. - Mailing list pgsql-hackers

From Andy Fan
Subject Re: UniqueKey on Partitioned table.
Date
Msg-id CAKU4AWqVcbkH5EnzPT=9hN_xkYZKiRvE2F9Er_qu3ihHoWY7ww@mail.gmail.com
Whole thread Raw
In response to Re: UniqueKey on Partitioned table.  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: UniqueKey on Partitioned table.  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers


On Wed, Mar 31, 2021 at 9:12 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
> b).  How to present the element
> in UniqueKey.  Prue EquivalenceClasses or Mix of Expr and EquivalenceClass as
> we just talked about.
I think the reason we add ECs for sort expressions is to use
transitive relationship. The EC may start with a single member but
later in the planning that member might find partners which are all
equivalent. Result ordered by one is also ordered by the other. The
same logic applies to UniqueKey as well, isn't it. In a result if a
set of columns makes a row unique, the set of columns represented by
the other EC member should be unique. Though a key will start as a
singleton it might EC partners later and thus thus unique key will
transition to all the members. With that logic UniqueKey should use
just ECs instead of bare expressions.

TBH, I haven't thought about this too hard, but I think when we build the
UniqueKey, all the ECs have been built already.  So can you think out an
case we start with an EC with a single member at the beginning and
have more members later for UniqueKey cases? 

--
Best Regards

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Next
From: David Rowley
Date:
Subject: Re: UniqueKey on Partitioned table.