Options to pace/avoid meta-queries

[philrz]

When the app executes a query on behalf of the user, in addition to executing that query (appended with slight modifications to enable pagination of results), it also executes several "meta-queries" behind the scenes to further assist with the UX. This includes:

1. Calls to lake service's "describe" endpoint to get information to help with syntax highlighting
2. A copy of the query with | count() appended is executed so the "Total Rows" can be populated
3. A copy of the query to find the min/max values of time values and bucketed counts for populating the stacked bar chart

These are currently executed in parallel, and this all seems quite reasonable for the common case since the app can assume the lake service is a process with plenty of resources.

That said, we recently were assisting a community zync user who had a unique use case. They were doing research to determine if it would be possible to run remote lake services in containers limited to only 128 MB of memory due to limited available resources in eventual deployment environments. For their specific queries and data, we found that there was enough memory to run the queries successfully on their own (e.g., via zed query or the lake API) but once they were executing the queries from the app these additional "meta-queries" running in parallel caused enough additional memory to be used in the container such that they were OOM-killed by the kernel.

We might consider making some adjustments to the app behavior to allow users to better cope in a situation like this. Just doing some initial brainstorming, a few possible approaches come to mind:

1. The app could still execute all the meta-queries just as it does currently, but there could be a configurable Setting that would allow them to be executed serially rather than in parallel, trading off some speed of UX for less spiky resource usage on the lake service.

2. The app could offer configurable Settings to disable certain meta-queries and the features they support, either individually or all at once, such that the user might choose to live without a populated stacked bar chart or the "Total Rows" count.

3. Rather than a configurable Setting, perhaps the app could offer an option to just execute the query in isolation without the meta-query such that the contents of the results pane would be updated but the other parts of the UI like the stacked bar chart and "Total Rows" count would remain at their previous values.