Re: Parallel Seq Scan

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Seq Scan
Date: 2015-11-15 23:30:36
Message-ID: 5649159C.2010400@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16/11/15 12:05, Robert Haas wrote:
> On Fri, Nov 13, 2015 at 10:46 AM, Thom Brown <thom(at)linux(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-11-16 00:14:12 Re: check for interrupts in set_rtable_names
Previous Message Robert Haas 2015-11-15 23:05:41 Re: Parallel Seq Scan