From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Thom Brown <thom(at)linux(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-18 05:48:10 |
Message-ID: | CAA4eK1JPJYC4VXMs_cwvELn=21M17qbaRqzXer5DVaGn9ZA4QA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 18, 2015 at 12:59 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Nov 12, 2015 at 10:23 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > 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.
>
> I suggest that we instead fix ExecParallelFinish() to be idempotent.
> Add a "bool finished" flag to ParallelExecutorInfo and return at once
> if it's already set. Get rid of the exposed
> ExecParallelReinitializeTupleQueues() interface and have
> ExecParallelReinitialize(pei) instead. Have that call
> ReinitializeParallelDSM(), ExecParallelSetupTupleQueues(pei->pcxt,
> true), and set pei->finished = false. I think that would give us a
> slightly cleaner separation of concerns between nodeGather.c and
> execParallel.c.
>
Okay, attached patch fixes the issue as per above suggestion.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
fix_finish_parallel_executor_info_v1.patch | application/octet-stream | 2.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2015-11-18 06:32:49 | Re: Freeze avoidance of very large table. |
Previous Message | Haribabu Kommi | 2015-11-18 05:32:04 | Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change |