5 ms·
It does. But when you're watching your database, and therefore your business, crash and burn because it decided to change the query plan for an important query,
by williamdclt 5y ago
It does. But when you're watching your database, and therefore your business, crash and burn because it decided to change the query plan for an important query, all these "problems with existing Hint systems" sound very irrelevant.
I'd love to have a way to lock a plan in a temporary "emergency measure" fashion. But of course it's hard/impossible to design this without letting people abuse it and pretend it's just a hint system.
- silon42 5y agoExactly... DB deciding to switch query plans in production is sometimes terrible.
- suddendescent 5y ago>I'd love to have a way to lock a plan in a temporary "emergency measure" fashion. Could this be achieved by extending prepared statements? [1] The dirty option would be to introduce a new keyword like PREPAREFIXED. The first time such a statement is executed, the execution plan could be stored and then retrieved on subsequent queries. There would be no hints and the changes in code should be minimal. Once a query runs successfully, the users can be sure that the execution plan won't change. >But of course it's hard/impossible to design this without letting people abuse it Is this more important than having predictable execution times? [1] https://www.postgresql.org/docs/current/sql-prepare.html https://www.postgresql.org/docs/current/sql-prepare.html
- williamdclt 5y ago> Is this more important than having predictable execution times? To me: no. To the Postgres team: apparently :)