Re: Why enable_hashjoin Completely disables HashJoin

On Mon, Apr 3, 2023 at 2:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Yeah, good point. I'm now remembering that at one point I'd had the
idea of running the whole find-a-plan-for-a-jointree step and then
running it a second time if it fails to find a plan. But I think that
requires some restructuring, because I think right now it does some
things that we should only do once we know we're definitely getting a
plan out. Or else we have to reset some state. Like if we want to go
back and maybe add more paths then we have to undo and redo whatever
set_cheapest() did.

> 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.

Yeah, I thought of that at one point too and rejected it for the same reason.

--
Robert Haas
EDB: http://www.enterprisedb.com