Re: [PATCH] Erase the distinctClause if the result is unique by definition - Mailing list pgsql-hackers

From David Rowley
Subject Re: [PATCH] Erase the distinctClause if the result is unique by definition
Date
Msg-id CAApHDvqBO-B-xr=XrUD+70u4hBxJyd_k9zAuX2j9=MjNX_gGhw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Erase the distinctClause if the result is unique by definition  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: [PATCH] Erase the distinctClause if the result is unique by definition  (Andy Fan <zhihui.fan1213@gmail.com>)
List pgsql-hackers
On Wed, 18 Mar 2020 at 15:57, Andy Fan <zhihui.fan1213@gmail.com> wrote:
> I'm now writing the code for partition index stuff, which
> is a bit of boring, since every partition may have different unique index.

Why is that case so different?

For a partitioned table to have a valid unique index, a unique index
must exist on each partition having columns that are a superset of the
partition key columns. An IndexOptInfo will exist on the partitioned
table's RelOptInfo, in this case.

At the leaf partition level, wouldn't you just add the uniquekeys the
same as we do for base rels? Maybe only do it if
enable_partitionwise_aggregation is on. Otherwise, I don't think we'll
currently have a need for them.  Currently, we don't do unique joins
for partition-wise joins. Perhaps uniquekeys will be a good way to fix
that omission in the future.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)
Next
From: Michael Paquier
Date:
Subject: Re: Online checksums verification in the backend