John Papandriopoulos <dr.jpap@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
