Re: Why enable_hashjoin Completely disables HashJoin

Andres Freund <andres(at)anarazel(dot)de> writes:
> 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.

Actually, I kind of like that. It would put the extra cost in a place
it belongs: if you have enough enable_foo turned off to prevent
generating a valid plan, it'll cost you extra to make a plan ... but
likely you'll be paying even more in runtime due to not getting a good
plan, so maybe that doesn't matter anyway. I'd limit it to two passes:
first try honors all enable_foo switches, second try ignores all.

I'm not quite sure how this could be wedged into the existing code
structure --- in particular I am not sure that we're prepared to do
two passes of baserel path generation. (GEQO is an existence proof
that we could handle it for join planning, though.)

Or we could rethink the design goal of not allowing enable_foo switches
to cause us to fail to make a plan. That might be unusable though.

regards, tom lane