Re: Why enable_hashjoin Completely disables HashJoin

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.

Off the top of my head I don't see why. It's not like the possible
plans are going to change on you often, only when DDL changes the
schema.

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. They
still get sequential scans where they're absolutely necessary such as
small reference tables with no usable index and rely on that
behaviour.

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.

But perhaps these sites would be better served with different
machinery anyways. If they actually did get a sequential scan on a
large table or any query where the estimate was very high where they
were expecting low latency OLTP queries perhaps they would prefer to
get an error than some weird plan anyways.

And for query planning debugging purposes of course it would be more
powerful to be able to enable/disable plan types per-node. That would
avoid the problem of not being able to effectively test a plan without
a sequential scan on one table when another table still needs it. But
that direction...

--
greg