Re: FailedAssertion on partprune
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Jaime Casanova <jaime.casanova@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-09T03:33:17Z
Lists: pgsql-hackers
I wrote: > Now that seems to me to be a rather weird plan: why doesn't it prefer > to flatten everything into one parallel append? Indeed, if you take > out any of the remaining query parts such as the LIMIT, that's what > it does. I think that its willingness to do this is actually kind > of a bug, because this query is going to be a total disaster in terms > of the number of workers it will try to use --- way more than the > user would expect given max_parallel_workers_per_gather = 2. Oh ... never mind that last. The parent Append will run its children sequentially, so that the Gathers execute one at a time, and at no point will more than 2 workers be active. Nonetheless, it's a damfool query plan, because we'll be going through parallel worker startup/shutdown overhead 4 times for no benefit. We really should put in some kind of logic to force those sibling Gathers to be aggregated into one, or else disallow them altogether. regards, tom lane
Commits
-
Remove bogus Assert in make_partitionedrel_pruneinfo().
- 69d0e7e6b81d 11.0 landed
- 59ef49d26d2f 12.0 landed
-
LLVMJIT: Adapt to API changes in gdb and perf support.
- 1b957e59b92d 11.0 cited
-
Rewrite the code that applies scan/join targets to paths.
- 11cf92f6e2e1 11.0 cited