On Tue, Aug 15, 2017 at 2:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Tom Lane <tgl@sss.pgh.pa.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.
Well, I think the point of force_parallel_mode is to try running
things in workers when it's legal but not necessarily beneficial, so
I'd be disinclined to nerf this too much, but it might be OK to nerf
it a little bit. Off-hand, I'd say the obvious options are:
(1) teach exec_simple_check_plan() to consider everything non-simple
when force_parallel_mode is not off, or
(2) teach exec_save_simple_expr() to see through a Gather node to the
Result node underneath
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
