On Mon, Jun 20, 2016 at 1:26 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I have done analysis on this and didn't found any use case where passing > CURSOR_OPT_PARALLEL_OK in exec_stmt_execsql() can help in parallelizing the > queries. Basically, there seems to be three ways in which function > exec_stmt_execsql can be used inside plpgsql. > > a. In execution of statement used in open cursor (via exec_stmt_open()) > b. In execution of statement when used in for loop (via exec_stmt_forc()) > c. In execution of SQL statement (via direct call to exec_stmt_execsql()) > > For the cases (a) and (b), one can construct a case where execution needs to > be suspended, so using parallel mode for those cases will not be meaningful. > For case (c), the Select statement seems to execute successfully only when > there is a *into* target, else it will give an error after execution as > below: > ERROR: query has no destination for result data > HINT: If you want to discard the results of a SELECT, use PERFORM instead. > > Now, if one has used into clause, the number of rows will be restricted in > which cases parallelism won't be enabled.
OK, sounds like I got that right, then. Thanks for verifying. -- 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
