On Thu, Jan 18, 2018 at 1:14 PM, Peter Geoghegan <p...@bowt.ie> wrote: > That seems pretty far fetched.
I don't think it is, and there are plenty of other examples. All you need is a query plan that involves significant CPU work both below the Gather node and above the Gather node. It's not difficult to find plans like that; there are TPC-H queries that generate plans like that. > 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? That's an excellent argument for making parallel CREATE INDEX ignore parallel_leader_participation entirely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
