Hello everybody, In the current version, queries in SQL or PL functions can not leverage parallelism. To relax this restriction I prepared a patch, the approach used in the patch is explained next,
Approach: 1. Allow parallelism for queries in PL functions by passing CURSOR_OPT_PARALLEL_OK instead of 0 to exec_prepare_plan called from exec_stmt_execsql or exec_stmt_dynexecute. Similarly, pass CURSOR_OPT_PARALLEL_OK instead of 0 to SPI_execute and exec_run_select called from exec_stmt_dynexecute. CURSOR_OPT_PARALLEL_OK is passed to these functions after checking if the statement is not trigger, since in that case using parallelism may not be efficient. 2. In ExecutePlan there is an additional check to see if the query is coming from SQL or PL functions and is having a parallel plan. In that case we ignore the check of numberTuples since it is always one for these functions and existing checks restrict parallelism for these cases. Though, I understand this may not be the most elegant way to do this, and would be pleased to know some better alternative. I have attached a sql file containing cases for some pgpsql, perl, python functions and an .out file which contains the parallel plans for the queries in these functions after this patch. This might be helpful in understanding the level of parallelism this patch is relaxing for PL functions. Thanks to my colleagues Amit Kapila and Dilip Kumar for discussions in this regard. -- Regards, Rafia Sabih EnterpriseDB: http://www.enterprisedb.com/
pl_parallel_v1.patch
Description: Binary data
pl_parallel.out
Description: Binary data
pl_parallel_test.sql
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers