Re: [HACKERS] Runtime Partition Pruning

On Wed, Nov 15, 2017 at 4:43 AM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On 15 November 2017 at 01:57, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>> I think to do this you're going to have to store some sort of array
>> that maps the partition index to the subpath in the Append node so you
>> can correctly identify the subpath based on what you're getting back
>> from get_partitions_for_keys(). Perhaps what you had worked previously
>> when we were not returning a Bitmapset with that function.
>>
>> Once you've got that design worked out I can take another look at this.
>

> So some sort of hierarchical structure of the partition hierarchy
> would need to be stored in the Append node and then you'd need to
> search at each level, and then somehow match the results up to the
> subpaths that you have in the Append. Although, I'm still not sure
> this is the best way to go about this.
>

Instead of hierarchical structure can’t we maintain an array (one
entry per partition), and whenever any leaf partition’s subpath
is added to the append rel (in function set_append_rel_pathlist) we
can set that subpath number in corresponding array index.

And, later we can add some wrapper over get_partitions_for_key such
that it can recursively traverse the non-leaf partitions (something
like get_partition_for_tuple does as Amit mentioned.). And, ultimately
gives the output as a list of leaf partition's indexes. Then we can
find the sub-plan number by looking into the array.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com