On Thu, Sep 29, 2022 at 04:12:06PM -0700, Peter Geoghegan wrote: > Offhand I'd say it's more likely to be too complicated. Without > meaning to sound glib, the first question that occurs to me is "will > we also need a conviction multiplier conviction multiplier?". Anything > like that is going to have unintended consequences that might very > well be much worse than the problem that you set out to solve. > > Personally I still like the idea of just avoiding unparameterized > nested loop joins altogether when an "equivalent" hash join plan is > available. I think of it as preferring the hash join plan because it > will have virtually the same performance characteristics when you have > a good cardinality estimate (probably very often), but far better > performance characteristics when you don't. We can perhaps be > approximately 100% sure that something like that will be true in all > cases, no matter the details. That seems like a very different concept > to what you've proposed.
I think the point the original poster as making, and I have made in the past, is that even of two optimizer costs are the same, one might be more penalized by misestimation than the other, and we don't have a good way of figuring that into our plan choices. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
