On Thu, Jun 21, 2018 at 4:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > We could probably fix it by using a significantly larger test case, > but that's not very attractive to put into the regression tests. > Anybody have a better idea about how to improve this? Or even a > clear explanation for what's causing it? (I'd expect coverage > instrumentation to impose costs at process exit, not startup.)
I don't know what's causing this to happen, but what jumps out at me is that worker 3 is the one that eats all of the rows, rather than, say, worker 0, or the leader. Normally what happens in parallel query -- pretty much by design -- is that the processes that are started earlier get going before the ones that are started later, and they finish gobbling up all the input before the others finish initializing. But here the last process that started was the only one that got to do any work. That seems mighty odd. Why should the leader get descheduled like that? And all the workers, too? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company