Hi Pavan,
Thanks for continuing to work on this.
On 2018/11/27 20:18, Pavan Deolasee wrote:
> Ok. I will try that approach again. In the meanwhile, I am posting a
> rebased version. There had been quite a lot changes on partitioning side
> and that caused non-trivial conflicts. I noticed a couple of problems
> during the rebase, but I haven't attempted to address them fully yet, since
> I think a detailed review at some point might require us to change that
> anyways.
>
> - Noticed that partColsUpdated is not set correctly in case of MERGE since
> we never get to call expand_partitioned_rtentry() for the partition table
> in case of MERGE. This right now does not cause significant problem, since
> we initialise the required states by other means. But we should fix this.
Regarding this, you may want to take a look at the following patch that
refactors things in this area.
https://commitfest.postgresql.org/20/1778/
Among other changes (such as completely redesigned inheritance_planner),
expand_partitioned_rtentry is now called after entering make_one_rel()
with the patch, which is much later than currently. That allows us to
initialize RTEs and RelOptInfos for only the partitions that are left
after pruning. As of now, it's called at a point in subquery_planner
where it's too soon to prune, so expand_partitioned_rtentry ends up
building RTEs for *all* partitions. I think that is something we're going
to have change in the long run anyway, so perhaps something you should
consider when designing related parts of MERGE. I will try to look at
that portion of your patch maybe next month.
Thanks,
Amit