Re: disable only nonparallel seq scan.

On Tue, Dec 10, 2019 at 1:32 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)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