Re: [COMMITTERS] pgsql: Simplify plpgsql's check for simple expressions.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-08-16T16:53:53Z
Lists: pgsql-hackers
On Wed, Aug 16, 2017 at 12:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Aug 16, 2017 at 11:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I can get on board with that statement. Can you draft a better wording? > >> Here is an attempt. Feel free to edit. > > I think s/plan/query/ in the last bit would be better. Perhaps > > + * However, if force_parallel_mode = on or force_parallel_mode = regress, > + * then we impose parallel mode whenever it's safe to do so, even if the > + * final plan doesn't use parallelism. It's not safe to do so if the query > + * contains anything parallel-unsafe; parallelModeOK will be false in that > + * case. Otherwise, everything in the query is either parallel-safe or > + * parallel-restricted, and in either case it should be OK to impose > + * parallel-mode restrictions. If that ends up breaking something, then > + * either some function the user included in the query is incorrectly > + * labelled as parallel-safe or parallel-restricted when in reality it's > + * parallel-unsafe, or else the query planner itself has a bug. > */ Works for me. I'm happy to phrase this in any way that makes it clear to you, 'cuz it's already clear to me. :-) You want to push something, or should I do it? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Attempt to clarify comments related to force_parallel_mode.
- 1e56883a528e 11.0 landed
-
Make simpler-simple-expressions code cope with a Gather plan.
- b73f1b5c29e0 11.0 landed
-
Simplify plpgsql's check for simple expressions.
- 00418c612441 11.0 cited