On 2016/06/20 15:42, Amit Kapila wrote:
> On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
>> fine for parallel seq scan.
>>
[ ... ]
>> For example, the above result shows,
>> Parallel Seq Scan : actual rows = 3333333
>> worker 0 : actual rows = 3457968
>> worker 1 : actual rows = 3741069
>> Summation of these is 10532370, but actual total rows is 10000000.
>> I think that Parallel Seq Scan should show actual rows =
>> 10000000(total rows) or actual rows = 2800963(rows collected by
>> itself). (10000000 maybe better)
>>
>
> You have to read the rows at Parallel Seq Scan nodes as total count of
> rows, but you have to consider the loops parameter as well.
>
>>
>> After spent time to investigate this behaviour, ISTM that the problem
>> is nloops of Parallel Seq Scan.
>> Parallel Seq Scan is done only once, but nloops is incremented to 3.
>>
>
> nloops here indicates, that it is done for 2 workers and a master backend.
Does the way parallel instrumentation info is currently handled allow to
also show the leader's info maybe like below:
-> Parallel Seq Scan on public.pgbench_accounts
(cost=0.00..205601.67 rows=4166667 width=0) (actual
time=0.042..1685.542 rows=3333333 loops=3)
Leader: actual time=x.xxx..xxxx.xxx rows=2800963 loops=1
Worker 0: actual time=0.033..1657.486 rows=3457968 loops=1
Worker 1: actual time=0.039..1702.979 rows=3741069 loops=1
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
