Re: Why enable_hashjoin Completely disables HashJoin

Greg Stark <stark(at)mit(dot)edu> writes:
> On Mon, 3 Apr 2023 at 19:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

> The only one that gives me pause is enable_seqscan. I've seen multiple
> sites that turn it off as a hammer to force OLTP-style plans.

Yeah, that. There are definitely people using some of these switches
in production, hence relying on the current (and documented) behavior.
On the whole I doubt we can get away with that answer.

> In that case we would ideally generate a realistic cost estimate for
> the unavoidable sequential scan to avoid twisting the rest of the plan
> in strange ways.

As I mentioned earlier, I think it might be possible to hack up the
seqscan case to avoid use of disable_cost pretty easily. It's far
easier to detect that no other plans are possible than it is once
you get to the join stage. Perhaps that's worth doing.

regards, tom lane