Re: PSA: --enable-coverage interferes with parallel query scheduling - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PSA: --enable-coverage interferes with parallel query scheduling
Date
Msg-id CA+Tgmoav1URNLHK7Lby4KXSUh_3ZoyKGa_iJYNOwAcgo0A97Rw@mail.gmail.com
Whole thread Raw
In response to PSA: --enable-coverage interferes with parallel query scheduling  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers >0)" when partitionwise_aggregate true.
Next
From: Sergey Cherkashin
Date:
Subject: Psql patch to show access methods info