Re: Inheritance planner CPU and memory usage change since 9.3.2
От | Tom Lane |
---|---|
Тема | Re: Inheritance planner CPU and memory usage change since 9.3.2 |
Дата | |
Msg-id | 4135.1434654854@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Inheritance planner CPU and memory usage change since 9.3.2 (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: Inheritance planner CPU and memory usage change since 9.3.2
|
Список | pgsql-hackers |
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On 18 June 2015 at 14:48, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: