Hi,
On 2023-04-03 14:04:30 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Apr 3, 2023 at 8:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Personally, I'd get rid of disable_cost altogether if I could.
> >> I'm not in a hurry to extend its use to more places.
>
> > I agree. I've wondered if we should put some work into that. It feels
> > bad to waste CPU cycles generating paths we intend to basically just
> > throw away, and it feels even worse if they manage to beat out some
> > other path on cost.
>
> > It hasn't been obvious to me how we could restructure the existing
> > logic to avoid relying on disable_cost.
>
> Yeah. In some places it would not be too hard; for example, if we
> generated seqscan paths last instead of first for baserels, the rule
> could be "generate it if enable_seqscan is on OR if we made no other
> path for the rel". It's much messier for joins though, partly because
> the same joinrel will be considered multiple times as we process
> different join orderings, plus it's usually unclear whether failing
> to generate any paths for joinrel X will lead to overall failure.
>
> A solution that would work is to treat disable_cost as a form of infinity
> that's counted separately from the actual cost estimate, that is we
> label paths as "cost X, plus there are N uses of disabled plan types".
> Then you sort first on N and after that on X. But this'd add a good
> number of cycles to add_path, which I've not wanted to expend on a
> non-mainstream usage.
It sounds too hard compared to the gains, but another way could be to plan
with the relevant path generation hard disabled, and plan from scratch, with
additional scan types enabled, if we end up being unable to generate valid
plan.
Greetings,
Andres Freund