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