On Tue, Dec 10, 2019 at 1:32 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes <jeff.ja...@gmail.com> 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
