Re: [HACKERS] path toward faster partition pruning

On Tue, Feb 6, 2018 at 3:25 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> Agreed. partition.c has gotten quite big and actually more than half of
> the code that this patch adds really seems to belong outside of it.
>
>> And it seems to me that the code you're adding
>> here is really quite similar to what we've already got in that
>> directory -- for example, predtest.c, which currently does partition
>> pruning, lives there; so does clauses.c, whose evaluate_expr facility
>> this patch wants to use; so does relnode.c, which the other patches
>> modify; and in general this looks an awful lot like other optimizer
>> logic that decomposes clauses. I'm open to other suggestions but I
>> don't think adding all of this directly into partition.c is a good
>> plan.
>
> Agreed.
>
> A partprune.c in the optimizer's util directory seems like a good place.

partprune.c looks to much tied to one feature. I am sure that the
functions used for partition pruning can be used by other
optimizations as well.

partition.c seems to have two kinds of functions 1. that build and
manage relcache, creates quals from bounds etc. which are metadata
management kind 2. partition bound comparison functions, and other
optimizer related functions. May be we should divide the file that
way. The first category code remains in catalog/ as it is today. The
second catagory functions move to optimizer/.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company