On Thu, Jun 21, 2018 at 4:00 PM, Tom Lane <tgl@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