Re: Parallel Seq Scan

On Thu, Oct 15, 2015 at 6:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Oct 15, 2015 at 7:00 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >
> > 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;
>

I don't think for such statements the control flow will set up an unshared
param list. I have tried couple of such statements [1] and found that
always such parameters are set up by setup_param_list(). I think there
are only two possibilities which could lead to setting up of unshared
params:

1. Usage of cursors - This is already prohibited for parallel-mode.
2. Usage of read-write-param - This only happens for expressions like
x := array_append(x, foo) (Refer exec_check_rw_parameter()). Read-write
params are not used for SQL statements. So this also won't be used for
parallel-mode

There is a chance that I might be missing some case where unshared
params will be required for parallel-mode (as of today), but if not then
I think we can live without current changes.

[1] -
1.
create or replace function parallel_func_params() returns integer
as $$
declare
param_val int;
ret_val int;
begin
param_val := 1000;
Select c1 into ret_val from t1 where c1 = param_val;
return ret_val;
end;
$$ language plpgsql;

For such a query, it will go in setup_param_list()

2.
create or replace function parallel_func_params_1() returns integer
as $$
declare
param_val int;
ret_val int;
begin
param_val := 1000;
Execute 'Select count(c1) from t1 where c1 = $1' Into ret_val Using
param_val;
return ret_val;
end;
$$ language plpgsql;

3.
create or replace function parallel_func_params_2() returns integer
as $$
declare
param_val int;
ret_val int;
row_var t1%ROWTYPE;
begin
param_val := 1000;
Select * into row_var from t1 where c1 = param_val;
return ret_val;
end;
$$ language plpgsql;

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