Re: Parallel Seq Scan

On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sun, Oct 11, 2015 at 7:56 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > I see no mention in this thread of varatt_indirect, but I anticipated
> > datumSerialize() reacting to it the same way datumCopy() reacts. If
> > datumSerialize() can get away without doing so, why is that?
>
> Good point. I don't think it can. Attached is a patch to fix that.
> This patch also includes some somewhat-related changes to
> plpgsql_param_fetch() upon which I would appreciate any input you can
> provide.
>
> plpgsql_param_fetch() assumes that it can detect whether it's being
> called from copyParamList() by checking whether params !=
> estate->paramLI. I don't know why this works, but I do know that this
> test fails to detect the case where it's being called from
> SerializeParamList(), which causes failures in exec_eval_datum() as
> predicted. Calls from SerializeParamList() need the same treatment as
> calls from copyParamList() because it, too, will try to evaluate every
> parameter in the list.
>

From what I understood by looking at code in this area, I think the check
params != estate->paramLI and code under it is required for parameters
that are setup by setup_unshared_param_list(). Now unshared params
are only created for Cursors and expressions that are passing a R/W
object pointer; for cursors we explicitly prohibit the parallel
plan generation
and I am not sure if it makes sense to generate parallel plans for
expressions
involving R/W object pointer, if we don't generate parallel plan where
expressions involve such parameters, then SerializeParamList() should not
be affected by the check mentioned by you. Is by anychance, this is
happening because you are testing by forcing gather node on top of
all kind of plans?

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