Database
When Is One Query per Template Enough? Adapting Learned Cost Models to New Hardware
arXiv cs.DB0 views
arXiv:2611.05892v1 Announce Type: new Abstract: A learned cost model that predicts query runtimes is trained on measurements from one machine. When the database moves to other hardware, its plans stay the same but their runtimes change, each by its own factor. We ask how to adapt such a model from k queries measured on the new machine: which queries to run, how to use their runtimes, and how many are enough. On PostgreSQL we timed the same plans of 1,162 TPC-H and TPC-DS queries in six environments: a laptop and a server, each with all its processors or pinned to one, the server also pinned to two, and the laptop also with a small buffer pool. No single factor describes the slowdown between two environments: most of its variance lies between query templates, so a speed factor stops improving after a few queries. A correction that fits separate lines for serial and parallel plans and adds an offset for every measured template brings the moved model, with one measured query per template, to an error (geometric mean over templates of the median Q-error) of 1.10 on TPC-H and 1.19 on TPC-DS, close to the same correction on a model trained on the new machine; fine-tuning a DACE-style neural cost model on the same queries gains at most 2%. On templates never measured, no correction we tried is on average more than 2% better than the speed factor. We then fixed hypotheses and timed new data. On TPC-H at ten times the scale the errors follow these results, but two of five repeated tests miss. On the Join Order Benchmark, whose queries differ widely within a template, the model errs by 2.36 even when retrained on the new machine, no correction gains much, and only the test on new templates holds; boosted trees and a neural model fit these queries better, and correcting the neural model works as well as fine-tuning it. We report every test as registered.
Source:https://arxiv.org/abs/2611.05892PreviousOptimizing Geo-replicated Deterministic DatabasesNextAutonomous ETL Pipelines for Salesforce M&A Consolidation: A Reference Framework, Jitterbit Mapping, and Reproducible Simulation Study
Related posts
VITI Science Exclusive: Erkki Laine on the BIGF Break-Glass Protocol 🚨
0dev.to

When Your Data Breaks on AWS (HA & DR Part 1): Aurora Backtrack, Idempotency, and the Delta Problem
0dev.to
How I Built a Custom Anti-Spam Rate Limiter for My PHP Site (No Cloudflare
0dev.to PHP
A PHP + MySQL attendance register: a weekend project for PHP training students
0dev.to Beginners

River Enqueues Jobs in Your Postgres Transaction. Keep It Out of Your Go Domain
0dev.to Go
SQL INNER JOIN vs LEFT JOIN vs RIGHT JOIN vs FULL OUTER JOIN: Differences With Examples (Tested in MySQL 8.4 and SQLite)
0dev.to Database