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