Re: [PATCH] Keeps tracking the uniqueness with UniqueKey - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Date
Msg-id CAExHW5sp=Cub2pQuEWQoP_jCOQdj65P8YXOOJVt-8tSgNObqqQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Andy Fan <zhihui.fan1213@gmail.com>)
List pgsql-hackers
On Sun, Dec 6, 2020 at 9:09 AM Andy Fan <zhihui.fan1213@gmail.com> wrote:
>>
>> I have not been following this thread closely enough to understand
>> why we need a new "UniqueKeys" data structure at all.
>
>
> Currently the UniqueKey is defined as a List of Expr, rather than EquivalenceClasses.
> A complete discussion until now can be found at [1] (The messages I replied to also
> care a lot and the information is completed). This patch has stopped at this place for
> a while,  I'm planning to try EquivalenceClasses,  but any suggestion would be welcome.
>
>>
>> But if the
>> motivation is only to remove this overspecification, I humbly suggest
>> that it ain't worth the trouble.

AFAIK, the simple answer is we need some way to tell that certain
expressions together form a unique key for a given relation. E.g.
group by clause forms a unique key for the output of GROUP BY.
Pathkeys have a stronger requirement that the relation is ordered on
that expression, which may not be the case with uniqueness e.g. output
of GROUP BY produced by hash grouping. To me it's Pathkeys - ordering,
so we could use Pathkeys with reduced strength. But that might affect
a lot of places which depend upon stronger pathkeys.

-- 
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: initscan for MVCC snapshot
Next
From: Daniel Gustafsson
Date:
Subject: Re: Refactor MD5 implementations and switch to EVP for OpenSSL