On Tue, Mar 27, 2018 at 3:08 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila <amit.kapil...@gmail.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
