| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Erase the distinctClause if the result is unique by definition |
| Date: | 2020-03-18 04:12:56 |
| Message-ID: | CAApHDvqBO-B-xr=XrUD+70u4hBxJyd_k9zAuX2j9=MjNX_gGhw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 18 Mar 2020 at 15:57, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-03-18 04:20:47 | Re: Online checksums verification in the backend |
| Previous Message | Justin Pryzby | 2020-03-18 03:37:01 | Re: Berserk Autovacuum (let's save next Mandrill) |