Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id 9689e056-5129-543b-3088-f83e1accdc48@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2017/12/09 0:57, Robert Haas wrote:
> On Thu, Dec 7, 2017 at 2:22 AM, Beena Emerson <memissemerson@gmail.com> wrote:
>> I have added the partition quals that are used for pruning.
>>
>> PFA the updated patch. I have changed the names of variables to make
>> it more appropriate, along with adding more code comments and doing
>> some refactoring and other code cleanups.
> 
> - I am surprised that set_append_subplan_indexes() needs to worry
> about multi-level partitioning directly.  I would have thought that
> Amit's patch would take care of that, just returning a Bitmapset of
> indexes which this function could use directly.

Actually, the partition.c code that my patch adds is limited to consider
one partitioned table at a time, not the whole tree.  As of 0a480502b09
[1], we call set_append_rel_size() separately for each partitioned table
in a partition tree.  In each such call, we call partition.c to perform
partition pruning for the given partitioned table.

In the run-time pruning case, we should get, via Append, a list of pruning
clauses for each partitioned table in the tree that survived plan-time
pruning.  Then, just like ExecFindPartition() calls
get_partition_for_tuple() for each partitioned table until we get to a
leaf partition, we should call partition.c for each un-pruned partitioned
table that have run-time pruning clauses associated.

Thanks,
Amit

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0a480502b09



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning
Next
From: Ildus Kurbangaliev
Date:
Subject: Re: [HACKERS] Custom compression methods