>Just out of curiosity, why is SPLIT / MERGE support not included for >HASH partitions? Because sibling partitions can have a different >modulus, you should be able to e.g. split a partition with (modulus, >remainder) of (3, 1) into two partitions with (mod, rem) of (6, 1) and >(6, 4) respectively, with the reverse being true for merge operations, >right?
You are right, SPLIT/MERGE operations can be added for HASH-partitioning in the future. But HASH-partitioning is rarer than RANGE- and LIST-partitioning and I decided to skip it in the first step. Maybe community will say that SPLIT/MERGE commands are not needed... (At first step I would like to make sure that it is no true)
P.S. I attached patch with 1-line warning fix (for cfbot). -- With best regards, Dmitry Koval
For attachPartTable, the parameter wqueue is missing from comment.
The parameters of CloneRowTriggersToPartition are called parent and partition. I think it is better to name the parameters to attachPartTable in a similar manner.
For struct SplitPartContext, SplitPartitionContext would be better name.
+ /* Store partition contect into list. */
contect -> context
Cheers
Hi,
For transformPartitionCmdForMerge(), nested loop is used to detect duplicate names.
If the number of partitions in partcmd->partlist, we should utilize map to speed up the check.
For check_parent_values_in_new_partitions():
+ if (!find_value_in_new_partitions(&key->partsupfunc[0], + key->partcollation, parts, nparts, datum, false)) + found = false;
It seems we can break out of the loop when found is false.
