On Wed, Mar 29, 2017 at 8:00 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > What is however strange is that changing max_parallel_workers_per_gather > affects row estimates *above* the Gather node. That seems a bit, um, > suspicious, no? See the parallel-estimates.log.
Thanks for looking at this! Comparing the parallel plan vs. the non-parallel plan: part: parallel rows (after Gather) 20202, non-parallel rows 20202 partsupp: parallel rows 18, non-parallel rows 18 part-partsupp join: parallel rows 88988, non-parallel rows 355951 lineitem: parallel rows 59986112, non-parallel rows 59986112 lineitem after aggregation: parallel rows 5998611, non-parallel rows 5998611 final join: parallel rows 131, non-parallel rows 524 I agree with you that that looks mighty suspicious. Both the part-partsupp join and the final join have exactly 4x as many estimated rows in the non-parallel plan as in the parallel plan, and it just so happens that the parallel divisor here will be 4. Hmm... it looks like the parallel_workers value from the Gather node is being erroneously propagated up to the higher levels of the plan tree. Wow. Somehow, Gather Merge managed to get the logic correct here, but Gather is totally wrong. Argh. Attached is a draft patch, which I haven't really tested beyond checking that it passes 'make check'. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
fix-gather-worker-propagation.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
