Re: Why enable_hashjoin Completely disables HashJoin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Quan Zongliang <quanzongliang(at)yeah(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why enable_hashjoin Completely disables HashJoin
Date: 2023-04-05 17:05:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-04-05 17:05:53 Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Previous Message Pavel Stehule 2023-04-05 16:40:30 Re: proposal: psql: show current user in prompt