On 16/11/15 12:05, Robert Haas wrote:
On Fri, Nov 13, 2015 at 10:46 AM, Thom Brown <t...@linux.com> wrote:
And perhaps associated PIDs?
Yeah, that can be useful, if others also feel like it is important, I can
look into preparing a patch for the same.
Thanks.
Thom, what do you think the EXPLAIN output should look like,
specifically? Or anyone else who feels like answering.
I don't think it would be very useful to repeat the entire EXPLAIN
output n times, once per worker. That sounds like a loser. But we
could add additional lines to the output for each node, like this:
Parallel Seq Scan on foo (cost=0.00..XXX rows=YYY width=ZZZ) (actual
time=AAA..BBB rows=CCC loops=1)
Leader: actual time=AAA..BBB rows=CCC loops=1
Worker 0: actual time=AAA..BBB rows=CCC loops=1
Worker 1: actual time=AAA..BBB rows=CCC loops=1
Worker 2: actual time=AAA..BBB rows=CCC loops=1
If "buffers" is specified, we could display the summary information
after the Parallel Seq Scan as normal and then display an additional
per-worker line after the "Leader" line and each "Worker N" line. I
think displaying the worker index is more useful than displaying the
PID, especially if we think that a plan tree like this might ever get
executed multiple times with different PIDs on each pass.
Like? Dislike? Other ideas?
Possibly have an option to include the PID?
Consider altering the format field width of the Worker number (depending
on the number of workers) so you don't get:
Worker 9 ...
Worker 10 ...
but something like
Worker 9 ...
Worker 10 ...
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
