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.
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