On Thu, Mar 23, 2017 at 11:26 PM, Robert Haas <robertmh...@gmail.com> wrote:
> > The changes to the plpgsql code don't look so good to me. The change > to exec_stmt_return_query fixes the same bug that I mentioned in the > email linked above, but only half of it -- it corrects the RETURN > QUERY EXECUTE case but not the RETURN QUERY case. And it's clearly a > separate change; that part is a bug fix, not an enhancement. My bad. Since, you have given this as a separate patch in the link upthread, I suppose there's nothing expected from me regarding this right now. > Some of > the other changes depend on whether we're in a trigger, which seems > irrelevant to whether we can use parallelism. Even if the outer query > is doing writes, we can still use parallelism for queries inside the > trigger function if warranted. It's probably a rare case to have > queries inside a trigger that are expensive enough to justify such > handling but I don't see the value of putting in special-case logic to > prevent it. > Fixed. I confused it with not allowing parallel workers when update command is in progress. > I suspect that code fails to achieve its goals anyway. At the top of > exec_eval_expr(), you call exec_prepare_plan() and unconditionally > pass CURSOR_OPT_PARALLEL_OK, so when that function returns, expr->plan > might now be a parallel plan. If we reach the call to > exec_run_select() further down in that function, and if we happen to > pass false, it's not going to matter, because exec_run_select() is > going to find the plan already initialized. > True, fixed. The attached patch is to be applied over [1]. [1] https://www.postgresql.org/message-id/CA%2BTgmoZ_ZuH%2BauEeeWnmtorPsgc_SmP%2BXWbDsJ%2BcWvWBSjNwDQ%40mail.gmail.com -- Regards, Rafia Sabih EnterpriseDB: http://www.enterprisedb.com/
pl_parallel_opt_support_v4.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