Re: FailedAssertion on partprune
От | Tom Lane |
---|---|
Тема | Re: FailedAssertion on partprune |
Дата | |
Msg-id | 30170.1533785597@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: FailedAssertion on partprune (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: FailedAssertion on partprune
Re: FailedAssertion on partprune |
Список | 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
В списке pgsql-hackers по дате отправления: