Re: Enabling parallelism for queries coming from SQL or other PL functions

On Wed, Mar 8, 2017 at 1:54 AM, Robert Haas <robertmhaas(at)gmail(dot)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-kShxQJ2uM5GPDze9fRYA@mail.gmail.com
--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/