Query Workbench - automatically prepare and run queries in one step

Background
You are able to specify parameters within query workbench which then get passed on to the query service as a parameterized query.

Often this is used as a feature to mimic a developer's application, especially from a prepared statement point of view where you would want to only declare a query once and then have the prepared plan used over and over again (avoiding re-calculation of the plan on every request).

This is a somewhat nuanced area of the query engine, since running a simple prepared query without parameters can provide a different query plan than the same prepared query which does use parameters.

A trivial example is as follows:

SELECT * FROM bucket WHERE id IN [1, 9999999999999999];

The same can be achieved using parameters:

SELECT * FROM bucket WHERE id IN $ids;

The query plan for the first query will scan the index from 1-1 and from 9999999999999999-9999999999999999, and these results are passed back to the query engine.

In the second query, a plan will be generated to scan the index from ARRAY_MIN($ids) to ARRAY_MAX($ids) before the results are passed back to the query engine.

As you can see, for the same query you can have vastly different execution times due to the fact that the index scan sizes are different.

Problem
Unfortunately, if you were a developer trying to debug this issue using query workbench then you would have no way of reproducing this 'slowness' due to the fact that you cannot use prepared statements from Query Workbench, even when specifying parameters.

While you can enhance your application to pull out the timings profile from the query response (assuming you enable timings, taking a performance hit on each query), you cannot then put these timings into the nice visual plan.

This makes the query workbench much less useful at debugging slow queries in your application.

Request
The ability to either run a query by first 'preparing' it and then sending it, probably through an opt-in option in the preferences.
Alternatively, the same could be achieved by not preparing the query, but instead asking the query engine to handle the parameterized query as though it was not adhoc (i.e. the parameters are not known before planning). This would likely require a change in query API.