upvote
Funnily enough, you could replace "LLM query planner" with just "query planner" and this comment would still hold true
reply
deleted
reply
That bug is fixable and verifiable. The LLM you cross your fingers till the next time the same thing happens.
reply
> fixable and verifiable

By people with a specific skill set. LLMs generation can also be fixed and verified by people with a certain skill set, and non-deterministic computing doesn't automatically mean unpredictable. When people say that the LLMs are a black box, it means unpredictability in unknown situations.

You do structured output, input validation, output validation, lower temperature, limit decisions, RL, etc. to increase predictability to near certainty. It's just statistics after all. Or you can as well generate the code to do the job.

It's just that the required skill set is a different one to do those things, and unusual in the context of DB administration.

reply
Only if someone is planning on running a pinned self hosted version of an LLM alongside the DB to fix the problem. The developer can change the binary easy enough and test it but the LLM approach just seems either theoretical or bending ourselves in knots to justify using an LLM.
reply
I didn't argue that it'd make sense, I just said that it could be reasonably fixable when problems occur and verifyable that the fix works. Even if shipping and RLing an LLM were easy tasks in terms of software distribution (they are not) we'd still hit the skill mismatch, as I said in my previous comment.

I just find the "all llms are non dererministic and therefore unreliable" narrative a bit backwards. All software that has more than 0 users needs to deal with non-determinism anyway :)

reply
This exact situation has happened to me with Postgres' stock query planner when an automatic analyze got a bad sample of a large table.
reply
I’ve seen this happen to SQL Server many times. Every time the solution is a stored proc with the recompile option enabled.
reply
The answer to every problem is to rebuild statistics. (And never use stored procedures. It's just a shitty API layer in the worst language imaginable, sitting outside of source control. If you need an API layer, write it in a real language, ideally the one you're already using.)
reply
Our database 12.34 was working great, but 12.35 deployment had some optimizer changes that had regression on exact scenario that you have in your statistics. Shit happens, sorry. Use this hint.
reply
deleted
reply