On Tue, May 16, 2017 at 3:30 PM, amul sul <sula...@gmail.com> wrote:
> On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat
> <ashutosh.ba...@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
0001-Cleanup_v2.patch
Description: Binary data
0002-hash-partitioning_another_design-v7.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
