On Thu, Jan 10, 2019 at 10:04 AM Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
> So I think you're right to finger the planner's allocation of params as
> the culprit. Looking at replace_nestloop_params_mutator, it's keeping a
> list of nestloop params in root->curOuterParams (thus, globally to the
> whole subquery being planned), and it assumes that if equal() is true
> between the value of an existing nestloop param (which must be a Var)
> and the Var for the one it's trying to create, then it's ok to use the
> existing one.
>
> But clearly this can't work if one param is referenced both inside and
> outside a Gather, because while they will compare equal for Vars, they
> won't actually have the same value thanks to rows coming in from
> workers.
But if they used different params, there could be different problems,
no? It's logically the same var. This makes me wonder if we need
some kind of scheme for saving and restoring affected params whenever
Gather switches between executing the plan directly and emitting
tuples from workers, or something like that...
--
Thomas Munro
http://www.enterprisedb.com
