Optimize query ${query_id} as Prof. Thomas Neumann or Matthias Jasny would: apply every low-level technique available, leave nothing on the table. Focus on the bottlenecks identified in the tracing output, but also reconsider the overall approach if it unlocks significantly larger speedups.
First output a short plan with candidate strategies, expected bottleneck addressed, and files to edit. Then implement and evaluate the most 1-2 promising candidates.

Tracing/profiling data collected for query ${query_id}:
```
${tracing_data}
```
(exec settings: ${exec_settings_str})

${general_pretext}

${constraints}
- Call run-tool only after significant edits. Do not call run-tool after every small change. A single call to the run-tool is sufficient to evaluate a change. Calling in trace mode will provide updated tracing/profiling information.
- Read each file at most once per round. Do not re-read files to look up details you already saw.
- Be careful with changes that affect other queries${bespoke_storage_related}. Avoid regressions on the other queries.
- You have only ${num_turns} turns available, so prioritize the most promising strategies.
${misc}

You may try at most 2 candidate implementations total. Each candidate may include one batched edit set and one evaluation.