From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(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:57:57 |
Message-ID: | CAKU4AWpxABop1ydF-478NXjObG8r-g2yy0=E1i2bf88HvjS04g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David:
On Wed, Mar 18, 2020 at 12:13 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> 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.
>
> The main difference are caused:
1. we can create unique index on some of partition only.
create table q100 (a int, b int, c int) partition by range (b);
create table q100_1 partition of q100 for values from (1) to (10);
create table q100_2 partition of q100 for values from (11) to (20);
create unique index q100_1_c on q100_1(c); // user may create this index
on q100_1 only
2. The unique index may not contains part key as above.
For the above case, even the same index on all the partition as well, we
still can't
use it since the it unique on local partition only.
3. So the unique index on a partition table can be used only if it
contains the partition key
AND exists on all the partitions.
4. When we apply the uniquekey_is_useful_for_rel, I compare the
information between ind->indextlist
and rel->reltarget, but the indextlist has a wrong varno, we we have to
change the varno with
ChangeVarNodes for the indextlist from childrel since the varno is for
childrel.
5. When we detect the uk = 1 case, the uk is also present with
parentrel->relid information, which
we may requires the ChangeVarNodes on childrel->indexinfo->indextlist as
well.
Even the rules looks long, The run time should be very short since
usually we don't have
many unique index on partition table.
> At the leaf partition level, wouldn't you just add the uniquekeys the
> same as we do for base rels?
Yes, But due to the uk of a childrel may be not useful for parent rel (the
uk only exist
in one partiton), so I think we can bypass if it is a child rel case?
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | keisuke kuroda | 2020-03-18 05:04:06 | Re: control max length of parameter values logged |
Previous Message | Amit Kapila | 2020-03-18 04:57:37 | Re: Missing errcode() in ereport |