diff options
| author | Robert Haas <rhaas@postgresql.org> | 2017-03-31 21:01:20 -0400 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2017-03-31 21:01:20 -0400 |
| commit | 7d8f6986b83c9a56f6ea11c959cdd8f52e1b543d (patch) | |
| tree | 6b070e57792e42ab817c186eae8dcf60793ad658 /src/backend/executor/nodeGatherMerge.c | |
| parent | 2113ac4cbb12b815804e8873d761cade9ddf49b9 (diff) | |
| download | postgresql-7d8f6986b83c9a56f6ea11c959cdd8f52e1b543d.tar.gz postgresql-7d8f6986b83c9a56f6ea11c959cdd8f52e1b543d.zip | |
Fix parallel query so it doesn't spoil row estimates above Gather.
Commit 45be99f8cd5d606086e0a458c9c72910ba8a613d removed GatherPath's
num_workers field, but this is entirely bogus. Normally, a path's
parallel_workers flag is supposed to indicate the number of workers
that it wants, and should be 0 for a non-partial path. In that
commit, I mistakenly thought that GatherPath could also use that field
to indicate the number of workers that it would try to start, but
that's disastrous, because then it can propagate up to higher nodes in
the plan tree, which will then get incorrect rowcounts because the
parallel_workers flag is involved in computing those values. Repair
by putting the separate field back.
Report by Tomas Vondra. Patch by me, reviewed by Amit Kapila.
Discussion: http://postgr.es/m/f91b4a44-f739-04bd-c4b6-f135bd643669@2ndquadrant.com
Diffstat (limited to 'src/backend/executor/nodeGatherMerge.c')
0 files changed, 0 insertions, 0 deletions