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