On 9 March 2016 at 04:06, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 5:15 PM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> 3. Nothing in create_grouping_paths() looks at the force_parallel_mode >> GUC. I had a quick look at this GUC and was a bit surprised to see 3 >> possible states, but no explanation of what they do, so I've not added >> code which pays attention to this setting yet. I'd imagine this is >> just a matter of skipping serial path generation when parallel is >> possible when force_parallel_mode is FORCE_PARALLEL_ON. I've no idea >> what FORCE_PARALLEL_REGRESS is for yet. > > The GUC is documented just like all the other GUCs are documented. > Maybe that's not enough, but I don't think "no explanation of what > they do" is accurate. But I don't see why this patch should need to > care about force_parallel_mode at all. force_parallel_mode is about > making queries that wouldn't choose to run in parallel do on their own > do so anyway, whereas this patch is about making more queries able to > do more work in parallel.
Hmm, it appears I only looked as far as the enum declaration, which I expected to have something. Perhaps I'm just not used to looking up the manual for things relating to code. The one reason that I asked about force_parallel_mode was that I assumed there was some buildfarm member running somewhere that switches this on and runs the regression tests. I figured that if it exists for other parallel features, then it probably should for this too. Can you explain why you think this should be handled differently? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
