Re: [HACKERS] Adding support for Default partition in partitioning
От | Jeevan Ladhe |
---|---|
Тема | Re: [HACKERS] Adding support for Default partition in partitioning |
Дата | |
Msg-id | CAOgcT0O3vvwH9KGZ6cURRT088PS5GybKC3+1MPGKY7H9wzOLuQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Adding support for Default partition in partitioning (Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Adding support for Default partition in partitioning
(Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>)
Re: [HACKERS] Adding support for Default partition in partitioning (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
I will work on a fix and send a patch shortly.
Attached is the V28 patch that fixes the issue reported by Rajkumar.
The patch series is exactly same as that of V27 series[1].
The fix is in patch 0002, and macro partition_bound_has_default() is
again moved in 0002 from 0003, as the fix needed to use it.
The fix is basically in get_partition_for_tuple() as below:
@@ -1973,30 +2209,46 @@ get_partition_for_tuple(PartitionDispatch *pd,
if (key->strategy == PARTITION_STRATEGY_RANGE)
{
- /*
- * Since we cannot route tuples with NULL partition keys through a
- * range-partitioned table, simply return that no partition exists
- */
for (i = 0; i < key->partnatts; i++)
{
if (isnull[i])
{
- *failed_at = parent;
- *failed_slot = slot;
- result = -1;
- goto error_exit;
+ /*
+ * We cannot route tuples with NULL partition keys through
+ * a range-partitioned table if it does not have a default
+ * partition. In such case simply return that no partition
+ * exists for routing null partition key.
+ */
+ if (!partition_bound_has_default(partdesc->boundinfo))
+ {
+ *failed_at = parent;
+ *failed_slot = slot;
+ result = -1;
+ goto error_exit;
+ }
+ else
+ {
+ /*
+ * If there is any null partition key, it would be
+ * routed to the default partition.
+ */
+ range_partkey_has_null = true;
+ break;
+ }
}
}
}
/*
- * A null partition key is only acceptable if null-accepting list
- * partition exists.
+ * If partition strategy is LIST and this is a null partition key,
+ * route it to the null-accepting partition. Otherwise, route by
+ * searching the array of partition bounds.
*/
cur_index = -1;
- if (isnull[0] && partition_bound_accepts_nulls(partdesc->boundinfo))
+ if (key->strategy == PARTITION_STRATEGY_LIST && isnull[0] &&
+ partition_bound_accepts_nulls(partdesc->boundinfo))
cur_index = partdesc->boundinfo->null_index;
- else if (!isnull[0])
+ else if (!range_partkey_has_null && !isnull[0])
{
The fix would be much easier if the refactoring patch 0001 by Amul in hash
partitioning thread[2] is committed.
The current code mixes the routing for list and range partitioning, and makes
it difficult to understand and fix any issues coming forward. I believe it will
be a good idea to keep the logic separate for both partitioning strategies.
Thoughts, view?
Regards,
Jeevan Ladhe
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Ashutosh BapatДата:
Сообщение: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Следующее
От: Jeevan LadheДата:
Сообщение: Re: [HACKERS] Adding support for Default partition in partitioning