Re: Explain buffers wrong counter with parallel plans

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explain buffers wrong counter with parallel plans
Date: 2018-08-02 09:41:39
Message-ID: CAA4eK1KwCx9qQk=Ko4LFTwoYg9B8TSccPAc=EoJR88rQpCYVdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 2, 2018 at 10:26 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Aug 2, 2018 at 8:38 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Hi,
>>
>> On 2018-08-02 08:21:58 +0530, Amit Kapila wrote:
>>> I think something on the lines what Tom and you are suggesting can be
>>> done with the help of EXEC_FLAG_BACKWARD, but I don't see the need to
>>> do anything for this patch. The change in nodeLimit.c is any way for
>>> forward scans, so there shouldn't be any need for any other check.
>>
>> I think this is almost a guarantee to introduce bugs in the future. And
>> besides that, as Robert points out, it's essentially an exiting bug for
>> custom scans. Given that EXEC_FLAG_BACKWARD already exists, why not do
>> the right thing here?
>>
>
> Sure, if we want we can do it in this patch, but this is not the
> problem of this patch. It is also related to existing usage of
> shutdown callbacks. I think we can use es_top_eflags in Estate to
> detect it and then call shutdown only if EXEC_FLAG_BACKWARD is not
> set. I think we should do that as a separate patch either before or
> after this patch rather than conflating that change into this patch.
> IIUC, then Robert also said that we should fix that separately. I
> will do as per whatever consensus we reach here.
>

I have created three patches (a) move InstrStartParallelQuery from its
original location so that we perform it just before ExecutorRun (b)
patch to fix the gather stats by calling shutdown at appropriate place
and allow stats collection in ExecShutdownNode (c) Probit calling
ExecShutdownNode if there is a possibility of backward scans (I have
done some basic tests with this patch, if we decide to proceed with
it, then some more verification and testing would be required).

I think we should commit first two patches as that fixes the problem
being discussed in this thread and then do some additional
verification for the third patch (mentioned in option c). I can
understand if people want to commit the third patch before the second
patch, so let me know what you guys think.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
postpone_buffer_usage_tracking_v1.patch application/octet-stream 1.2 KB
fix_gather_stats_v2.patch application/octet-stream 2.3 KB
prohibit_shutdown_backward_scans_v1.patch application/octet-stream 1.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Geoff Winkless 2018-08-02 09:41:52 Re: Have an encrypted pgpass file
Previous Message Adrien NAYRAT 2018-08-02 09:41:33 Re: [HACKERS] Parallel Append implementation