Horton

Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Hubert Lubaczewski <depesz@depesz.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>
Date: 2017-11-28T16:12:47Z
Lists: pgsql-hackers 
On Tue, Nov 28, 2017 at 2:23 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> That is wrong and I think you have hit a bug.  It should be 2974 * 5 =
> 14870 as you have seen in other cases.  The problem is that during
> rescan, we generally reinitialize the required state, but we forgot to
> reinitialize the instrumentation related memory which is used in the
> accumulation of stats, so changing that would fix some part of this
> problem which is that at Parallel node, you won't see wrong values.
> However, we also need to ensure that the per-worker details also get
> accumulated across rescans.  Attached patch should fix the problem you
> are seeing.  I think this needs some more analysis and testing to see
> if everything works in the desired way.
>
> Is it possible for you to test the attached patch and see if you are
> still seeing any unexpected values?

FWIW, this looks sensible to me.  Not sure if there's any good way to
write a regression test for it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Back-port fix for accumulation of parallel worker instrumentation.

  2. Test instrumentation of Hash nodes with parallel query.

  3. Try again to fix accumulation of parallel worker instrumentation.

  4. Revert "Fix accumulation of parallel worker instrumentation."

  5. Fix accumulation of parallel worker instrumentation.