Re: Inheritance planner CPU and memory usage change since 9.3.2

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 18 June 2015 at 14:48, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I feel I might be missing a trick here. It seems unlikely to me that
>> we actually need the entire append_rel_list for every subquery; and we
>> almost certainly don't need to modify every element of the
>> append_rel_list for every subquery. Even the ones that no
>> ChangeVarNodes() call mutates still get deep-copied.

> Yeah, you could probably pre-compute the indexes of the RTEs that need
> to copied, outside of the big loop, and store them in a bitmapset.
> Then, instead of copying the entire list of rowmarks/append_rel_infos
> each time, you could just copy the ones that referred to those RTE
> indexes (and only if the bitmapset was non-empty, which is the
> equivalent of your second optimisation). However, for AppendRelInfos,
> ChangeVarNodes() descends into the Vars in the translated_vars list,
> so short-cutting the copying of the AppendRelInfo isn't obviously
> safe. But, looking more closely, does ChangeVarNodes actually need to
> examine translated_vars (the fall-through case) when child_relid isn't
> the old rt_index? If not, that could be a big saving in cases like
> this.

I'm a bit surprised that duplicating the append_rel_list is a noticeable
performance problem. It ought to be far smaller than the Query tree that
we've always duplicated in this loop --- in particular, it's really a
subset of what we have in the RTE list, no?

regards, tom lane