Re:What's new in the Postgres 16 query planner (a.k.a. optim...
by hyperpape on Friday February 09, 2024 @07:58AM
(#39314360)
I'm sure there are reasons the implementation might not be easy, but conceptually this seems fixable. You just need a lower bound of "how bad can this plan be?" and that doesn't require completing the query, just observing that it's been running for a long time and/or used unreasonable amounts of resources.
Also, is the problem with the 50 join query that the planner screws it up, or that it's fundamentally doing too much?
Also, is the problem with the 50 join query that the planner screws it up, or that it's fundamentally doing too much?