Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT

John Papandriopoulos <dr(dot)jpap(at)gmail(dot)com> writes:
> The memory issue has indeed disappeared---there was no noticeable memory increase in the three queries below, with 4096 children. Inheritance planning overhead is around 20x for UPDATE/DELETE compared to SELECT; thankfully they are required much less frequently in my case.

> I am still wondering whether the inheritance_planner(...) can be avoided if the rowtypes of children are the same as the parent?

Possibly, but it's far from a trivial change. The difficulty is that
you'd need to generate a different plan tree structure.
inheritance_planner generates a separate subtree for each target table,
so that the ModifyTable node can execute each one separately and know
a priori which target table the rows coming out of a particular subplan
apply to. If we expand inheritance "at the bottom" like SELECT does,
that table identifier would have to propagate up as part of the returned
rows. It's doable but not simple. Moreover, it's far from clear this
actually would save much, and it could easily slow things down at
execution time.

Have you done any profiling work to see where the extra time goes?
I had thought that the unreferenced RTE entries would simply be ignored
in each subplanning step, but maybe there's something that is examining
them.

regards, tom lane