Re: Problem with default partition pruning - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Problem with default partition pruning
Date
Msg-id 20190315.173007.147577546.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to RE: Problem with default partition pruning  ("Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp>)
Responses Re: Problem with default partition pruning
List pgsql-hackers
Hello.

At Fri, 15 Mar 2019 15:05:41 +0900, "Yuzuko Hosoya" <hosoya.yuzuko@lab.ntt.co.jp> wrote in
<001901d4daf5$1ef4f640$5cdee2c0$@lab.ntt.co.jp>
> v2 patch attached.
> Could you please check it again?

I have some comments on the patch itself.

The patch relies on the fact(?) that the lowest index is always
-1 in range partition and uses it as pseudo default
partition. I'm not sure it is really the fact and anyway it
donsn't seem the right thing to do. Could you explain how it
works, not what you did in this patch?


L96:
>                      /* There can only be zero or one matching partition. */
> -                    if (partindices[off + 1] >= 0)
> -                        result->bound_offsets = bms_make_singleton(off + 1);
> -                    else
> -                        result->scan_default =
> -                            partition_bound_has_default(boundinfo);
> +                    result->bound_offsets = bms_make_singleton(off + 1);

The comment had a meaning for the old code. Seems to need rewrite?

L183:
> +                /*                                                                                                
> +                 * All bounds are greater than the key, so we could only                                          
> +                 * expect to find the lookup key in the default partition.                                        
> +                 */

Long trailing spaces are attached to every line without
substantial modification.

L198:
> -                 * inclusive, no need add the adjacent partition.
> +                 * inclusive, no need add the adjacent partition.  If 'off' is
> +                 * -1 indicating that all bounds are greater, then we simply
> +                 * end up adding the first bound's offset, that is, 0.

 off doesn't seem to be -1 there.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "Kuroda, Hayato"
Date:
Subject: RE: Is PREPARE of ecpglib thread safe?
Next
From: Michael Paquier
Date:
Subject: Re: Offline enabling/disabling of data checksums