On Thu, Jan 18, 2018 at 6:21 AM, Robert Haas <robertmh...@gmail.com> wrote: > Amit's reply to this part drew my attention to it. I think this is > entirely false. Consider an aggregate that doesn't support partial > aggregation, and a plan that looks like this: > > Aggregate > -> Gather > -> Parallel Seq Scan > Filter: something fairly selective > > It is quite possible for this to be superior to a non-parallel plan > even with only 1 worker and no parallel leader participation. The > worker can evaluate the filter qual, and the leader can evaluate the > aggregate. If the CPU costs of doing those computations are high > enough to outweigh the costs of shuffling tuples between backends, we > win.
That seems pretty far fetched. But even if it wasn't, my position would not change. This could happen only because the planner determined that it was the cheapest plan when parallel_leader_participation happened to be off. But clearly a "degenerate parallel CREATE INDEX" will never be faster than a serial CREATE INDEX, and there is a simple way to always avoid one. So why not do so? I give up. I'll go ahead and make parallel_leader_participation=off allow a degenerate parallel CREATE INDEX in the next version. I think that it will make parallel_leader_participation less useful, with no upside, but there doesn't seem to be much more that I can do about that. -- Peter Geoghegan
