On Mon, Oct 9, 2017 at 4:44 PM, amul sul <sula...@gmail.com> wrote:

> 0002 few changes in partition-wise join code to support
> hash-partitioned table as well & regression tests.

+    switch (key->strategy)
+    {
+        case PARTITION_STRATEGY_HASH:
+            /*
+             * Indexes array is same as the greatest modulus.
+             * See partition_bounds_equal() for more explanation.
+             */
+            num_indexes = DatumGetInt32(src->datums[ndatums - 1][0]);
+            break;
This logic is duplicated at multiple places.  I think it's time we consolidate
these changes in a function/macro and call it from the places where we have to
calculate number of indexes based on the information in partition descriptor.
Refactoring existing code might be a separate patch and then add hash
partitioning case in hash partitioning patch.

+        int        dim = hash_part? 2 : partnatts;
Call the variable as natts_per_datum or just natts?

+                                    hash_part? true : key->parttypbyval[j],
+                                    key->parttyplen[j]);
parttyplen is the length of partition key attribute, whereas what you want here
is the length of type of modulus and remainder. Is that correct? Probably we
need some special handling wherever parttyplen and parttypbyval is used e.g. in
call to partition_bounds_equal() from build_joinrel_partition_info().

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to