On 6 January 2018 at 07:31, Beena Emerson <memissemerson@gmail.com> wrote:
> It does not handle change in column order (varattno) in subpartitions.
Thanks for testing and finding that. I completely overlooked applying
translation of the prune qual so that it's compatible with the
sub-partition.
I've fixed this in the attached, but I did so by calling
adjust_appendrel_attrs() from the nodeAppend.c, which did, of course,
mean that the AppendRelInfo needed to be given to the executor. I was
also a bit unsure what exactly I should be doing in primnodes.h, since
I've put PartitionPruneInfo in there, but AppendRelInfo is not. I
stuck a quick declaration of AppendRelInfo in primnode.h with an XXX
comment so we don't forget to think about that again.
In all honesty, this calling planner code from the executor seems like
quite new ground for PostgreSQL, so I'm really not sure if we're
breaking any major rules or not with we've got now. Perhaps the saving
grace here is that we're not teaching the executor how to do anything
smart with these data structures, they're just given to it to pass
back to the planner function at the appropriate moment.
I've also borrowed and simplified your test case to ensure this fix
remains working. I added another level of partitioning with another
partition that has the columns in a different order again. This is to
ensure the translation code translates from the quals of the previous
level up, not the top-level. That's required since the AppendRelInfo
is only translating 1 level at a time.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services