| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions. |
| Date: | 2017-08-15 18:34:58 |
| Message-ID: | 23425.1502822098@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Simplify plpgsql's check for simple expressions.
> ...
> https://git.postgresql.org/pg/commitdiff/00418c61244138bd8ac2de58076a1d0dd4f539f3
The buildfarm members that are running force_parallel_mode = regress
are not happy with this. Apparently, even a trivial SELECT <expression>
can be turned into a Gather plan if force_parallel_mode says so.
I assume (haven't looked) that I could hack the plpgsql code to prevent
generating a parallel plan when it's decided the command is a simple
SELECT. But I wonder whether that's the right place to fix it. Does
it ever make sense to parallelize a plan that can't possibly benefit?
IOW I am not sure that we should carry force_parallel_mode this far.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-08-15 18:47:20 | pgsql: doc: Improve PDF bookmarks |
| Previous Message | Tom Lane | 2017-08-15 18:06:09 | pgsql: Avoid out-of-memory in a hash join with many duplicate inner key |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2017-08-15 18:36:22 | Re: What users can do with custom ICU collations in Postgres 10 |
| Previous Message | Peter Eisentraut | 2017-08-15 18:33:56 | Re: What users can do with custom ICU collations in Postgres 10 |