On Sat, Mar 24, 2018 at 8:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Yeah, sometimes that kind of stuff change performance characteristics,
>> but I think what is going on here is that create_projection_plan is
>> causing the lower node to build physical tlist which takes some
>> additional time. I have tried below change on top of the patch series
>> and it brings back the performance for me.
>
> I tried another approach inspired by this, which is to altogether skip
> building the child scan tlist if it will just be replaced. See 0006.
> In testing here, that seems to be a bit better than your proposal, but
> I wonder what your results will be.
>
..
>
> It looks in my testing like this still underperforms master on your
> test case. Do you get the same result?
>
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.
Test case
--------------
DO $$
DECLARE count integer;
BEGIN
For count In 1..1000000 Loop
Execute 'explain Select count(ten) from tenk1';
END LOOP;
END;
$$;
The average of ten runs on the master is 31593.9533 and with all the
patches applied it is 34008.7341. The patch takes approximately 7.6%
more time. I think this patch series is doing something costly in the
common code path. I am also worried that the new code proposed by you
in 0003* patch might degrade planner performance for partitioned rels,
though I have not tested it yet. It is difficult to say without
testing it, but before going there, I think we should first
investigate whats happening in the non-partitioned case.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
