Horton

Re: Explain buffers wrong counter with parallel plans

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "Jonathan S. Katz" <jonathan.katz@excoventures.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Adrien Nayrat <adrien.nayrat@anayrat.info>, Andres Freund <andres@anarazel.de>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-08-01T14:27:34Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> ... But scanning backwards is
> a problem.  I'm not exactly sure what the best way of handling that
> is, but one thing I think might work is to save ExecutePlan's
> execute_once flag in the EState and then make the call in nodeLimit.c
> and the one in ExecutePlan itself conditional on that flag.  If we
> know that the plan is only going to be executed once, then there can
> never be any backward fetches and it's fine to shut down as soon as we
> finish going forward.

Shouldn't this be dealt with by a eflag bit passed down at executor
init time?  What you're describing sounds a lot like somebody
invented a different way because they were unfamiliar with eflags.

			regards, tom lane

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.