SWatcher+ shows why the best cardinality model can still be the wrong deployment policy

A learned cardinality estimator does not run against a frozen database. Rows arrive, old rows disappear, query mixes change, and yesterday’s accurate model can steer today’s optimizer toward a bad plan. A new benchmark of SWatcher+ argues that the relevant score is therefore not estimation error alone, but end-to-end query time after monitoring, correction and retraining costs are counted together. Source

The result

The authors integrated SWatcher+ with PostgreSQL and three learned estimators: MSCN, JGMP and Naru. On the DSB workload, SWatcher+ with MSCN used 44.3% to 101.4% of the end-to-end runtime of periodic refresh across 16 query templates, winning on 14 of 16. The comparison is unusually strict: the periodic refresh interval was selected optimally after the fact. With JGMP, SWatcher+ used 56.1% to 99.5% of periodic-refresh runtime; with Naru, 87.84% to 98.84%. Those are runtime ratios, not accuracy scores, and they should not be mixed with Q-error leaderboards. Source

The dynamic DSB setup advances a 60-day window: the initial database covers one 60-day interval and, after 60 update steps, the final database contains the next interval. Depending on the query template, the experiment processes 0.08 million to 1.55 million relevant updates. The paper also checks IMDB/JOB-light by shifting the production_year window from 1900–1959 to 1960–2019. These are workload-specific update simulations, not a public hidden test or production trace. Source

Why it matters

SWatcher+ does not continuously maintain every possible cardinality. It watches subqueries whose correction is expected to change plan performance, keeps exact counts where that is affordable, and stores cheaper compensating factors for joins. It retrains when too many consequential estimates require correction, rather than when an aggregate error threshold is crossed. The benchmark’s central point is operational: correcting every estimate can cost more than it saves, while correcting only single-table selections can even produce worse plans. Source

That changes how learned-estimator results should be read. A model can improve median estimation accuracy yet lose once update processing, inference, monitoring and retraining enter the denominator. SWatcher+ is strongest where it evaluates that whole loop instead of reporting a static-model score. Source

The caveat

The evidence is still one paper’s PostgreSQL implementation, primarily on synthetic DSB dynamics, with IMDB/JOB-light as a secondary check. The arXiv version does not establish independent reproduction or portability to commercial optimizers. The useful claim is narrower: under the disclosed workloads, selective monitoring and correction beat a generously tuned periodic-refresh baseline across the tested models. That is enough to make end-to-end adaptation cost a benchmark requirement—not enough to declare periodic retraining obsolete. Source