| 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-16 02:50:54 |
| Message-ID: | CA+TgmobmB9HEgGYRUsW04gpK1ueSvs_OY5412d696mGHukVOiQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 15, 2016 at 10:48 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> exec_stmt_execsql() is used to execute SQL statements insider plpgsql which
> includes dml statements as well, so probably you wanted to play safe by not
> allowing parallel option from that place. However, I think there shouldn't
> be a problem in using CURSOR_OPT_PARALLEL_OK from this place as we have a
> check in standard_planner which will take care of whether to choose parallel
> mode or not for a particular statement. If you want, I can do more detailed
> analysis and prepare a patch.
That would be great. I have a vague recollection that that function
might be called in some contexts where execution can be suspended,
which would be no good for parallel query. But that might be wrong.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-06-16 03:06:32 | Re: Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it |
| Previous Message | Amit Kapila | 2016-06-16 02:48:59 | Re: parallel.c is not marked as test covered |