From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(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-12 15:35:40 |
Message-ID: | CAA-aLv5zrjCNpei1VFfAcA7sszGZCorzOp=cekV5FHR3xAk5Yw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12 November 2015 at 15:23, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Nov 11, 2015 at 11:29 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>>
>> Hi
>>
>> I have a first query
>>
>> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
>> differen
>>
>
> Thanks for the report. The reason for this problem is that instrumentation
> information from workers is getting aggregated multiple times. In
> ExecShutdownGatherWorkers(), we call ExecParallelFinish where it
> will wait for workers to finish and then accumulate stats from workers.
> Now ExecShutdownGatherWorkers() could be called multiple times
> (once we read all tuples from workers, at end of node) and it should be
> ensured that repeated calls should not try to redo the work done by first
> call.
> The same is ensured for tuplequeues, but not for parallel executor info.
> I think we can safely assume that we need to call ExecParallelFinish() only
> when there are workers started by the Gathers node, so on those lines
> attached patch should fix the problem.
That fixes the count issue for me, although not the number of buffers
hit, or the actual time taken.
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-11-12 15:37:00 | Re: checkpointer continuous flushing |
Previous Message | Greg Stark | 2015-11-12 15:29:23 | Re: LLVM miscompiles numeric.c access to short numeric var headers |