Re: disable only nonparallel seq scan.
On Tue, Dec 10, 2019 at 1:32 PM Robert Haas wrote: > On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes wrote: > > Is there a way to force a meaningful parallel seq scan, or at least the > planning of one, when the planner wants a non-parallel one? > > > > Usually I can do things like with with enable_* setting, but if I `set > enable_seqscan to off`, it penalizes the parallel seq scan 8 times harder > than it penalizes the non-parallel one, so the plan does not switch. > > > > If I set `force_parallel_mode TO on` then I do get a parallel plan, but > it is a degenerate one which tells me nothing I want to know. > > > > If I `set parallel_tuple_cost = 0` (or in some cases to a negative > number), I can force it switch, but that destroys the purpose, which is to > see what the "would have been" plan estimates are for the parallel seq scan > under the default setting of the cost parameters. > > > > I can creep parallel_tuple_cost downward until it switches, and then try > to extrapolate back up, but this tedious and not very reliable. > > I don't think there's a way to force this, but setting both > parallel_setup_cost and parallel_tuple_cost to 0 seems to often be > enough. > Yes, that is fine if I want the actual execution results. And I patch guc.c to allow negative settings, for when some extra persuasion is needed. But here I want to see what the planner is thinking, and changing the *cost settings changes that thinking. So I want to force the planner to choose the "next-best" plan under the original cost settings so I can see how far away they are from each other. I made a crude patch to add enable_singleseqscan, which has been letting me get at this information now. I'm not proposing to apply this particular patch to the code base, but I do wonder if we can do something about this "dark spot" which no combination of current enable_* setting seems to be able to get at. Cheers, Jeff enable_singleseqscan.patch Description: Binary data
Re: disable only nonparallel seq scan.
On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes wrote: > Is there a way to force a meaningful parallel seq scan, or at least the > planning of one, when the planner wants a non-parallel one? > > Usually I can do things like with with enable_* setting, but if I `set > enable_seqscan to off`, it penalizes the parallel seq scan 8 times harder > than it penalizes the non-parallel one, so the plan does not switch. > > If I set `force_parallel_mode TO on` then I do get a parallel plan, but it is > a degenerate one which tells me nothing I want to know. > > If I `set parallel_tuple_cost = 0` (or in some cases to a negative number), I > can force it switch, but that destroys the purpose, which is to see what the > "would have been" plan estimates are for the parallel seq scan under the > default setting of the cost parameters. > > I can creep parallel_tuple_cost downward until it switches, and then try to > extrapolate back up, but this tedious and not very reliable. I don't think there's a way to force this, but setting both parallel_setup_cost and parallel_tuple_cost to 0 seems to often be enough. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
disable only nonparallel seq scan.
Is there a way to force a meaningful parallel seq scan, or at least the planning of one, when the planner wants a non-parallel one? Usually I can do things like with with enable_* setting, but if I `set enable_seqscan to off`, it penalizes the parallel seq scan 8 times harder than it penalizes the non-parallel one, so the plan does not switch. If I set `force_parallel_mode TO on` then I do get a parallel plan, but it is a degenerate one which tells me nothing I want to know. If I `set parallel_tuple_cost = 0` (or in some cases to a negative number), I can force it switch, but that destroys the purpose, which is to see what the "would have been" plan estimates are for the parallel seq scan under the default setting of the cost parameters. I can creep parallel_tuple_cost downward until it switches, and then try to extrapolate back up, but this tedious and not very reliable. Cheers, Jeff
