On Fri, Oct 16, 2015 at 2:29 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> Yeah, but I think the scenario is legitimate. When a query gets run >> from within PL/pgsql, parallelism is an option, at least as we have >> the code today. So if a Gather were present, and the query used a >> parameter, then you could have this issue. For example: >> >> SELECT * FROM bigtable WHERE unindexed_column = some_plpgsql_variable; >> > > I don't think for such statements the control flow will set up an unshared > param list. I have tried couple of such statements [1] and found that > always such parameters are set up by setup_param_list(). I think there > are only two possibilities which could lead to setting up of unshared > params: > > 1. Usage of cursors - This is already prohibited for parallel-mode. > 2. Usage of read-write-param - This only happens for expressions like > x := array_append(x, foo) (Refer exec_check_rw_parameter()). Read-write > params are not used for SQL statements. So this also won't be used for > parallel-mode > > There is a chance that I might be missing some case where unshared > params will be required for parallel-mode (as of today), but if not then > I think we can live without current changes.
*shrug* The gather-test stuff isn't failing for no reason. Either PL/pgsql shouldn't be passing CURSOR_OPT_PARALLEL_OK, or having a parallel plan get generated there should work. There's not a third option. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
