From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.
Date: Tue, 15 Aug 2017 16:08:14 -0400
Message-ID: <31094.1502827694@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoaRuLrYSonO5y4-Dhiaw13yTukKWyJuRuCy2XHEAQ5O8A@mail.gmail.com>
References: <E1dhehy-00034e-8N@gemulon.postgresql.org>
<23425.1502822098@sss.pgh.pa.us>
<CA+TgmoaRuLrYSonO5y4-Dhiaw13yTukKWyJuRuCy2XHEAQ5O8A@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 15, 2017 at 2:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
Fair enough.
> 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
I had been looking into (3) get plpgsql to drop the CURSOR_OPT_PARALLEL_OK
bit when it decides the query is simple. But because (a) that bit is set
before we make the test, in current behavior, and (b) there are various
SPI interfaces in the way of changing it later, that approach is looking
pretty messy.
I like your plan (2). It's not much code and it lends itself to having a
run-time check, rather than just an Assert, that we found a Result node.
That seems like a good idea now that we've found the assumption isn't
bulletproof. However, do we need to worry about the planner putting some
nontrivial computation into the Gather's tlist instead of the Result?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.
In-Reply-To: <31094.1502827694@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox