When Not to Hint: Adapting an LLM Query Optimizer to a New Database Instance

Query optimization is the problem of determining how to efficiently execute a SQL statement, and errors in a database's cost model can leave a query running orders of magnitude slower than necessary. Recent systems fine-tune large language models to correct these mistakes with a hint (a directive that constrains the optimizer's choices) and supervise the models with labels obtained from executing candidate plans on a single server and recording the fastest. Supervision of this kind is representative of the instance that produced it: under the hint labels released with LLMOpt, a fine-tuned hint generator for PostgreSQL, the Join Order Benchmark runs on our own instance at under half the speed of the default optimizer, and models we fine-tune on the labels similarly underperform. We show that to adapt such a model to a new database instance, full local relabeling and retraining is not required. We relabel 5.8% of training queries with the locally fastest option including not hinting, continue training the model on the result, and a gate based on the default optimizer's cost estimates then selects a sampled hint. On the benchmark, the resulting pipeline opts to hint on roughly a third of queries, achieving a speedup of 1.451× on them and an overall speedup of 1.081×, reliably above both the default optimizer and the foreign-labeled model it starts from.