On Mon, Jun 20, 2016 at 1:26 AM, Amit Kapila <amit.kapila16@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
