On Mon, Jan 28, 2019 at 3:17 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm really unhappy that force_parallel_mode and > parallel_leader_participation are being treated as planner GUCs. > They are not that, IMO, because they also affect the behavior of > the executor, cf HandleParallelMessage, ExecGather, ExecGatherMerge. > This is somewhere between ill-considered and outright broken: what > happens if the values change between planning and execution?
The only use of parallel_leader_participation at plan time seems to be to twiddle the costing, and the use of it in the executor is to decide whether to have the leader participate. So if the values differ, you'll get a plan running a behavior for which plan selection was not optimized. I don't know whether it's useful to intentionally allow this so that you can see how the same plan behaves under the other setting, or whether it's just a wart we'd be better off without. It might be confusing, though, if you change the setting and it doesn't force a replan. Similarly, the use of force_parallel_mode in HandleParallelMessage() really just affects what CONTEXT lines you get. That may be ill-considered but it doesn't seem outright broken. Here again, I'm not really sure that forcibly preserving the plan-time value at execution time would really result in happier users. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
