On Tue, Mar 27, 2018 at 10:59 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> If we don't want to go with the upperrel logic, then maybe we should >>> consider just merging some of the other changes from my previous patch >>> in 0003* patch you have posted and then see if it gets rid of all the >>> cases where we are seeing a regression with this new approach. >> >> Which changes are you talking about? > > I realized that this version could be optimized in the case where the > scanjoin_target and the topmost scan/join rel have the same > expressions in the target list. >
Good idea, such an optimization will ensure that the cases reported above will not have regression. However isn't it somewhat beating the idea you are using in the patch which is to avoid modifying the path in-place? In any case, I think one will still see regression in cases where this optimization doesn't apply. For example, DO $$ DECLARE count integer; BEGIN For count In 1..1000000 Loop Execute 'explain Select sum(thousand)from tenk1 group by ten'; END LOOP; END; $$; The above block takes 43700.0289 ms on Head and 45025.3779 ms with the patch which is approximately 3% regression. In this case, the regression is lesser than the previously reported cases, but I guess we might see bigger regression if the number of columns is more or with a different set of queries. I think the cases which can slowdown are where we need to use physical tlist in create_projection_plan and the caller has requested CP_LABEL_TLIST. I have checked in regression tests and there seem to be more cases which will be impacted. Another such example from regression tests is: select count(*) >= 0 as ok from pg_available_extension_versions; -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
