Yes, yes. PostgreSQL developers don't care about messy real world use cases. News at 11. I reiterate that no optimizer is perfect. Which means that if Postg

Yes, yes. PostgreSQL developers don't care about messy real world use cases. News at 11. I reiterate that no optimizer is perfect. Which means that if PostgreSQL redid some obscure statistic and a common query just switched to a far worse query plan, you've got a disaster and no easy way to fix it. Even if you know the right query plan, there is no easy way to fix it. Similarly "this query worked fine in development and staging, but mysteriously sucks in production" is not what you want to learn while deploying to production. Yes, I've seen both failure modes. No it wasn't pretty. And no, "File a bug report, wait for the next version of PostgreSQL to have a fix" is not an acceptable action plan. In general if you've got a working site and working queries, there are two possible outcomes to changing the query plan. Either nobody notices because the plan was already good enough. Or everybody is upset because the new plan is worse. I don't care if 99% of the time it turns out well and nobody notices, that 1% keeps people up at night. The top missing feature in PostgreSQL is this. If the query plan is good, allow the query plan to get locked and not change. Predictability beats perfection in production environments.