| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> | 
|---|---|
| To: | amul sul <sulamul(at)gmail(dot)com> | 
| Cc: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Subject: | Re: With commit 4e5fe9ad19, range partition missing handling for the NULL partition key | 
| Date: | 2017-11-22 09:06:28 | 
| Message-ID: | ad4f3a9a-9819-b6b3-4ffe-7698f5dbbed6@lab.ntt.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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 | Content-Type | Size | 
|---|---|---|
| range_null_values-3.patch | text/plain | 2.4 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2017-11-22 09:21:27 | Re: default range partition and constraint exclusion | 
| Previous Message | Amit Langote | 2017-11-22 08:59:48 | Re: [HACKERS] path toward faster partition pruning |