One query per template can move a cost model—until the template stops being predictive
A new PostgreSQL study reaches 1.10 Q-error on TPC-H and 1.19 on TPC-DS after a hardware move, then watches most preregistered tests fail on JOB.
A learned database cost model does not necessarily need a new training set after a hardware move. In a new PostgreSQL study, a correction built from one measured query per template reduced the geometric mean of template-level median Q-error to 1.10 on TPC-H at scale factor 1 and 1.19 on TPC-DS at scale factor 1. The important qualifier is in the paper’s second round: the same idea largely stopped helping on the Join Order Benchmark (JOB), where queries inside one template varied much more widely. The paper and artifact were posted November 4.
What was measured
The author timed the same saved plans for 1,162 queries from 115 TPC-H and TPC-DS templates in six environments. They included a 22-thread Intel laptop, a 64-vCPU AMD server, processor-pinned variants, a two-processor server variant and a laptop configuration with a 128 MB PostgreSQL buffer pool. PostgreSQL 18.6, planner settings and plans were held fixed, so the experiment isolates environment-driven runtime changes.
TPC-H SF1 contributed 680 queries from 22 templates; TPC-DS SF1 contributed 482 queries from 93 templates. Each environment ran every query in three passes, with one warm-up and three timed executions per pass. A label was the median over passes of the median timed runs. Queries were split within each template into a measurement pool and a held-out test set. The score was the geometric mean across templates of each template’s median test Q-error.
The proposed correction fits separate relationships for serial and parallel plans, then adds an offset for each measured template. With round-robin selection at one query per template, it reached 1.10 Q-error at k=25 on TPC-H and 1.19 at k=100 on TPC-DS. A single global speed factor stayed at 1.37 at k=25 and 1.45 at k=25, respectively. At the one-query-per-template budgets, the correction’s 90th-percentile per-query Q-error was 1.39 versus 1.87 for the speed factor on TPC-H and 1.42 versus 2.03 on TPC-DS.
The negative result matters more
The extension used 220 TPC-H queries at scale factor 10 and all 113 JOB queries from 33 templates. TPC-H SF10 repeated the pattern: at k=100, the correction scored 1.12, level with the 1.12 no-move control and close to the 1.11 target-trained oracle.
JOB did not. At one query per template, the correction scored 2.41, barely better than the 2.48 speed factor and slightly worse than the 2.36 oracle. Even on the target hardware, the model itself was inaccurate. JOB queries within a template varied by a factor of 2.31 in median geometric standard deviation, versus 1.30 on TPC-H and 1.09 on TPC-DS. Random selection beat round robin, 2.36 to 2.41, and k-center plus nearest-neighbor reached 3.03, worse than the 2.71 unadapted model.
That failure was not hidden after the fact. The author registered hypotheses before the extension labels existed and reported every test. On JOB, only the new-template test held; the other registered tests failed. The artifact publishes the queries, plans, labels, study plan, amendments and scripts.
The practical result is narrower and stronger than “one query per template is enough.” It is enough when templates actually group queries with similar behavior and the source model already predicts within-template variation. Before adopting the shortcut, measure that variation—and keep a target-trained oracle in the evaluation so adaptation gains are not confused with the model’s own ceiling.
sources
comments · 0