On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas <robertmh...@gmail.com> wrote:
> There are two places where we currently set CURSOR_OPT_PARALLEL_OK in > PL/pgsql: exec_stmt_return_query() sets it when calling > exec_dynquery_with_params(), and exec_run_select() calls it when > calling exec_prepare_plan() if parallelOK is set. The latter is OK, > because exec_run_select() runs the plan via > SPI_execute_plan_with_paramlist(), which calls _SPI_execute_plan(), > which calls _SPI_pquery(). But the former is broken, because > exec_stmt_return_query() executes the query by calling > SPI_cursor_fetch() with a fetch count of 50, and that calls > _SPI_cursor_operation() which calls PortalRunFetch() -- and of course > each call to PortalRunFetch() is going to cause a separate call to > PortalRunSelect(), resulting in a separate call to ExecutorRun(). > Oops. > Fixed. The attached patch is over execute_once.patch [1]. I haven't addressed the issue regarding the confusion I raised upthread about incorrect value of !es->lazyeval that is restricting parallelism for simple queries coming from sql functions, as I am not sure if it is the concern of this patch or not. [1] https://www.postgresql.org/message-id/ca+tgmobxehvhbjtwdupzm9bvslitj-kshxqj2um5gpdze9f...@mail.gmail.com -- Regards, Rafia Sabih EnterpriseDB: http://www.enterprisedb.com/
pl_parallel_opt_support_v2.patch
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