Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Mar 27, 2018 at 3:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> For me, it is equivalent to the master. The average of ten runs on
>> the master is 20664.3683 and with all the patches applied it is
>> 20590.4734. I think there is some run-to-run variation, but more or
>> less there is no visible degradation. I think we have found the root
>> cause and eliminated it. OTOH, I have found another case where new
>> patch series seems to degrade.
>
> All right, I have scaled my ambitions back further. Here is a revised
> and slimmed-down version of the patch series.
>

It still didn't help much. I am seeing the similar regression in one
of the tests [1] posted previously.

> If we forget about
> "Remove explicit path construction logic in create_ordered_paths" for
> now, then we don't really need a new upperrel. So this patch just
> modifies the toplevel scan/join rel in place, which should avoid a
> bunch of overhead in add_path() and other places, while hopefully
> still fixing the originally-reported problem.
>

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. I
think that with this approach you want to target the problem of
partitonwise aggregate, but maybe we can deal with it in a separate
patch.

[1] -
Test case
--------------
DO $$
DECLARE count integer;
BEGIN
For count In 1..1000000 Loop
Execute 'explain Select count(ten) from tenk1';
END LOOP;
END;
$$;

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com