On Mon, 3 Apr 2023 at 19:32, Tom Lane <t...@sss.pgh.pa.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
