On Wed, Jul 15, 2015 at 1:50 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> One issue which I think we should fix in this patch as pointed earlier
> is, in some cases, Function containing Select stmt won't be able to
> use parallel plan even though it is marked as parallel safe.
>
> create or replace function parallel_func_select() returns integer
> as $$
> declare
> ret_val int;
> begin
> Select c1 into ret_val from t1 where c1 = 1;
> return ret_val;
> end;
> $$ language plpgsql Parallel Safe;
>
> Above function won't be able to use parallel plan for Select statement
> because of below code:
>
> static int
> exec_stmt_execsql(PLpgSQL_execstate *estate,
> PLpgSQL_stmt_execsql
> *stmt)
> {
> ..
> if (expr->plan == NULL)
> {
> ..
> exec_prepare_plan(estate, expr, 0);
> }
> ..
> }
>
> As the cursorOptions passed in this function are always 0, planner
> will treat it as unsafe function. Shouldn't we need to check parallelOk
> to pass cursoroption in above function as is done in exec_run_select()
> in patch?
exec_stmt_execsql is called by exec_stmt_open and exec_stmt_forc.
Those are cursor operations and thus - I think - parallelism can't be
used there. I think it would be OK to enable parallelism when we are
using it to execute a toplevel SQL statement, but I didn't do it
because I wasn't entirely sure that we couldn't pass the same
stmt->sqlstmt into exec_stmt_execsql from multiple contexts, some of
which are parallel-safe and others not. I don't think that can
happen, but my understanding of PL/pgsql is not the greatest.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
