Horton

Re: Explain buffers wrong counter with parallel plans

Adrien NAYRAT <adrien.nayrat@anayrat.info>

View thread View on postgr.es
From: Adrien Nayrat <adrien.nayrat@anayrat.info>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-04-30T14:35:07Z
Lists: pgsql-hackers 
On 04/29/2018 05:10 PM, Amit Kapila wrote:
> Yeah, it would have been convenient, if Gather and Finalize Aggregate
> displays that way as it would have been easier for users to
> understand.  However, as of now, the aggregated stats for parallel
> workers and leader are displayed at parallel/partial nodes as is
> displayed in the plan.  So according to me, what you are seeing is
> okay, it is only slightly tricky to understand it.
> 
[...]
> 
>> I played with git bisect and I found this commit :
>>
>> commit 01edb5c7fc3bcf6aea15f2b3be36189b52ad9d1a
>> Author: Tom Lane <tgl@sss.pgh.pa.us>
>> Date:   Fri Sep 1 17:38:54 2017 -0400
>>
> I think you were seeing different results before this commit because
> before that we were shutting down workers as soon as parallel workers
> are done and the buffer_usage stats were accumulated and were being
> used for upper nodes.  According to me behavior after the commit is
> consistent, for example, I think if you check the case of GatherMerge
> before this commit, you will still get the stats in the way it is
> after commit.

I understand. Maybe, this change should be mentioned in releases notes and/or
documentation?

Thanks,

Commits

  1. Adjust comment atop ExecShutdownNode.

  2. Prohibit shutting down resources if there is a possibility of back up.

  3. Fix buffer usage stats for parallel nodes.

  4. Match the buffer usage tracking for leader and worker backends.

  5. Improve division of labor between execParallel.c and nodeGather[Merge].c.