On Tue, Mar 27, 2018 at 10:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila <amit.kapila16@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