On Wed, Nov 15, 2017 at 4:43 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 15 November 2017 at 01:57, David Rowley <david.row...@2ndquadrant.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
