On Thu, Mar 23, 2017 at 12:41 AM, Rafia Sabih <rafia.sa...@enterprisedb.com> wrote: > Agree, done.
OK, committed execute-once-v3.patch after some further study. See also https://www.postgresql.org/message-id/CA%2BTgmoZ_ZuH%2BauEeeWnmtorPsgc_SmP%2BXWbDsJ%2BcWvWBSjNwDQ%40mail.gmail.com which resulted from that study. Regarding pl_parallel_opt_support_v3.patch, the change to init_execution_state looks good. Whether or not it's safe to use parallel query doesn't depend on whether the function is marked volatile, so the current code is just silly (and, arguably, readonly_func is misnamed). The changes to spi.c also seem fine; both of those functions execute the plan to completion and don't allow cursor operations, so we're good. 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. 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers