From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Clément Prévost <prevostclement(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel.c is not marked as test covered |
Date: | 2016-06-20 16:07:53 |
Message-ID: | CA+Tgmoba286JnAV-E8vEbj9Hqw9PgFauNn50fph+ogA2QCGSJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 20, 2016 at 1:26 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2016-06-20 16:26:44 | Re: 10.0 |
Previous Message | David G. Johnston | 2016-06-20 16:07:27 | Re: 10.0 |