Separate leader buffer info and worker wait info in EXPLAIN output? - Mailing list pgsql-hackers

From Thomas Munro
Subject Separate leader buffer info and worker wait info in EXPLAIN output?
Date
Msg-id CAEepm=3TBJew4h2u11ow8ROEMisrHhJs_=ymiaaMne91bP1qJA@mail.gmail.com
Whole thread Raw
Responses Re: Separate leader buffer info and worker wait info in EXPLAIN output?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi hackers,

EXPLAIN can show per-worker information and aggregated information,
but doesn't show the leader's information individually.  Should it?

Example:
 Partial Aggregate [...]   Output: PARTIAL count(*)   Buffers: shared hit=476   Worker 0: actual time=5.110..5.110
rows=1loops=1     Buffers: shared hit=150   Worker 1: actual time=5.088..5.088 rows=1 loops=1     Buffers: shared
hit=149

Presumably in that case the leader hit 476 - 150 - 149 = 175 shared
buffers, but why don't we just say so?

In my Parallel Hash proposal I'm showing Leader info separately:
 Parallel Hash [...]   Buckets: 32768  Batches: 1   Leader:    Shared Memory Usage: 1088kB  Tuples Hashed: 13440
Batches Probed: 1   Worker 0:  Shared Memory Usage: 1088kB  Tuples Hashed: 3960
Batches Probed: 1   Worker 1:  Shared Memory Usage: 1088kB  Tuples Hashed: 2600
Batches Probed: 1   ->  Parallel Seq Scan on [...]

The Leader line goes away if you set parallel_leader_participation =
off (using a patch I posted recently) due to lack of data.

The above is about about increasing visibility of the leader's
contribution, but it would also be good to be able to see how the
leader is hurting you by running the plan itself.  Would it make sense
to instrument the tuple queue interactions so we can show per-worker
shm_mq_send_bytes wait count and wait time?

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Commits don't block for synchronous replication
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning