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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers