On Tue, May 16, 2017 at 3:30 PM, amul sul <sulamul@gmail.com> wrote:
> On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat
> <ashutosh.bapat@enterprisedb.com> wrote:
> [...]
>>>>
>>>> + if (key->strategy == PARTITION_STRATEGY_HASH)
>>>> + {
>>>> + ndatums = nparts;
>>>> + hbounds = (PartitionHashBound **) palloc(nparts *
>>>> +
>>>> sizeof(PartitionHashBound *));
>>>> + i = 0;
>>>> + foreach (cell, boundspecs)
>>>> + {
>>>> + PartitionBoundSpec *spec = lfirst(cell);
>>>> +
>>>> [ clipped ]
>>>> + hbounds[i]->index = i;
>>>> + i++;
>>>> + }
>>>> For list and range partitioned table we order the bounds so that two
>>>> partitioned tables have them in the same order irrespective of order in which
>>>> they are specified by the user or hence stored in the catalogs. The partitions
>>>> then get indexes according the order in which their bounds appear in ordered
>>>> arrays of bounds. Thus any two partitioned tables with same partition
>>>> specification always have same PartitionBoundInfoData. This helps in
>>>> partition-wise join to match partition bounds of two given tables. Above code
>>>> assigns the indexes to the partitions as they appear in the catalogs. This
>>>> means that two partitioned tables with same partition specification but
>>>> different order for partition bound specification will have different
>>>> PartitionBoundInfoData represenation.
>>>>
>>>> If we do that, probably partition_bounds_equal() would reduce to just matching
>>>> indexes and the last element of datums array i.e. the greatest modulus datum.
>>>> If ordered datums array of two partitioned table do not match exactly, the
>>>> mismatch can be because missing datums or different datums. If it's a missing
>>>> datum it will change the greatest modulus or have corresponding entry in
>>>> indexes array as -1. If the entry differs it will cause mismatching indexes in
>>>> the index arrays.
>>>>
>>> Make sense, will fix this.
>>
>> I don't see this being addressed in the patches attached in the reply to Dilip.
>>
>
> Fixed in the attached version.
>
v6 patch has bug in partition oid mapping and indexing, fixed in the
attached version.
Now partition oids will be arranged in the ascending order of hash
partition bound (i.e. modulus and remainder sorting order)
Regards,
Amul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers