Re: With commit 4e5fe9ad19, range partition missing handling for theNULL partition key - Mailing list pgsql-hackers

From Amit Langote
Subject Re: With commit 4e5fe9ad19, range partition missing handling for theNULL partition key
Date
Msg-id ad4f3a9a-9819-b6b3-4ffe-7698f5dbbed6@lab.ntt.co.jp
Whole thread Raw
In response to Re: With commit 4e5fe9ad19, range partition missing handling for theNULL partition key  (amul sul <sulamul@gmail.com>)
Responses Re: With commit 4e5fe9ad19, range partition missing handling for theNULL partition key  (Rushabh Lathia <rushabh.lathia@gmail.com>)
List pgsql-hackers
On 2017/11/22 17:42, amul sul wrote:
> On Wed, Nov 22, 2017 at 11:38 AM, Amit Langote wrote:
>> On 2017/11/22 13:45, Rushabh Lathia wrote:
>>> Attaching patch to fix as well as regression test.
>>
>> Thanks for the patch.  About the code, how about do it like the attached
>> instead?
>>
> 
> Looks good to me, even we can skip the following change in v2 patch:
> 
> 19 @@ -2560,6 +2559,8 @@ get_partition_for_tuple(Relation relation,
> Datum *values, bool *isnull)
>  20                      */
>  21                     part_index =
> partdesc->boundinfo->indexes[bound_offset + 1];
>  22                 }
>  23 +               else
>  24 +                   part_index = partdesc->boundinfo->default_index;
>  25             }
>  26             break;
>  27
> 
> default_index will get assign by following code in get_partition_for_tuple() :
> 
>    /*
>      * part_index < 0 means we failed to find a partition of this parent.
>      * Use the default partition, if there is one.
>      */
>     if (part_index < 0)
>         part_index = partdesc->boundinfo->default_index;

Good point.  Updated patch attached.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Amit Langote
Date:
Subject: Re: default range partition and constraint exclusion