UX: ability to influence the order of queries execution order in a query suite/pack

[disconnect3d]

It would be awesome if CodeQL allowed for influencing the order in which queries are run/evaluated in a query suite definition.

This would enhance the user experience of CodeQL in cases where a big query suite is run over a large project. By having a possibility to tell that certain queries should evaluate at the end, it would allow the users to stop the codeql database analyze and gather partial results from the already evaluated (and likely fast) queries and then re-run the analyzer to just work over the last possible queries.

Please see also: #17930 and #17928.

[jketema]

Hi @disconnect3d. Thanks for your suggestion, we'll take this into consideration. I believe this is likely not something we can change easily, as CodeQL tries very hard to only evaluate each predicate once even when used in multiple queries.

[hmakholm]

By having a possibility to tell that certain queries should evaluate at the end, it would allow the users to stop the codeql database analyze and gather partial results from the already evaluated (and likely fast) queries and then re-run the analyzer to just work over the last possible queries.

Note that this is unlikely to be the kind of win you probably imagine. The QL evaluator doesn't evaluate queries one by one -- it aggressively shares intermediate results between different queries, and if you kill it halfway through, most of the context it could have used for subsequent evaluation will be lost, and will have to be recomputed when it restarts.

What we probably could do is to use the position of query suites or individual queries on the command like as a tiebreaker priority when there are more than one piece of work the evaluator could proceed with.

Apart from that possibility, however, my recommendation would be simply to run CodeQL several times over the same database with different queries (or an increasing set of queries and the --no-rerun option). When the evaluator shuts down nicely (and is not given an --expect-discarded-cache flag) it will save some strategically chosen intermediate results to disk so they can be reused by subsequent evaluations that use the same language library.