Re: Parallel Seq Scan

On Thu, Oct 15, 2015 at 7:00 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> 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?

Yeah, but I think the scenario is legitimate. When a query gets run
from within PL/pgsql, parallelism is an option, at least as we have
the code today. So if a Gather were present, and the query used a
parameter, then you could have this issue. For example:

SELECT * FROM bigtable WHERE unindexed_column = some_plpgsql_variable;

So this can happen, I think, even with parallel sequential scan only,
even if Gather node is not otherwise used.

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