Re: Why enable_hashjoin Completely disables HashJoin

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 3, 2023 at 8:13 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane