limit the number of instructions that can be evaluated #2459
Conversation
|
As much as I hate to admit it, I wonder if we've gotten to the point where it would be simpler to just parse and analyze the SQL. I still believe it would be infeasible to rely exclusively on analyzing SQL to support the query macros but in the much more limited case of answering the question, "does the query do anything to this column that could cause it to be null," I think analyzing SQL could be a more maintainable solution than heuristic analysis on SQLite bytecode. |
|
I think it would also be more approachable for new contributors because, let's face it, if something happened to you @tyrelr (gods forbid), I wouldn't even know where to start here. |
I agree that we're near the limits of what can be done with a naive approach of try-all-the-branches. But I do like that the current approach is tied to 'what sqlite' is doing (or at least my & previous committers comprehension of that). So I would probably fear parsing & analyzing the SQL opening a different set of headaches (sqlite syntax extensions, different behaviour than actual sqlite, etc.). I have considered ways to make this stuff more approachable though (exposing the describe command as sqlx command line operation so that log messages won't swallowed by the compilation proc? better ways of visualizing the execution traces calculated by sqlx?). As at least from what I see, being able to 'poke' it is the biggest hurdle. |
The current query explain implementation can make compilation appear to freeze during more complicated queries, due to an explosion of branches/loops now that most branching instructions are handled correctly.
This adds a fixed limit on the amount of effort to put into evaluating the explain of a single query. This could impact query analysis correctness, but avoids an enormous run time.