---
title: Learned Cost Models (LCMs)
url: https://www.emergentmind.com/topics/learned-cost-models-lcms
type: topic
---

# Learned Cost Models (LCMs)

Searching arXiv for recent papers on learned cost models and related systems.
Learned Cost Models (LCMs) are learned predictors used to estimate execution cost from structured descriptions of candidate computations, most often query plans, plan graphs, or placement graphs. In database systems, the dominant target is runtime or execution time rather than a symbolic optimizer score, and the main motivation is that hand-crafted cost formulas rely on simplifying assumptions that can badly misestimate performance. The same design pattern now appears in cross-engine SQL routing, UDF-aware optimization, distributed stream processing, compiler placement on reconfigurable hardware, unit-commitment screening, and symbolic planning, although the learned quantity and the integration point vary substantially across domains [2201.00561][2506.02802][2503.23863][2403.08444][2511.01872][2212.00483][2408.10889].

## 1. Definition, boundaries, and problem settings

In the contemporary database literature, an LCM is typically a supervised model trained on executed plans or queries to predict runtime for new plans. The zero-shot database line formulates the problem as physical query cost estimation from featurized plans and database statistics, with runtimes as labels; the cross-engine line extends the target to a vector of execution times over multiple engines and provisionings; and explainability work treats the output as a scalar runtime prediction whose internal dependencies should be inspectable at plan-node level [2201.00561][2506.02802][2507.14495].

Beyond single-engine relational optimization, closely related systems broaden both the target and the operational setting. COSTREAM predicts a vector \(C=(T,L_p,L_e,R_O,S)\) for operator placement in edge-cloud stream processing, where throughput and latencies are regression targets while backpressure occurrence and query success are binary targets [2403.08444]. A compiler LCM for reconfigurable dataflow hardware predicts normalized throughput of a placement-and-routing decision and uses that prediction inside a simulated-annealing-style placer [2511.01872]. In unit commitment, the learned quantity is the optimal UC cost \(J(\boldsymbol{\ell})\) as a function of load, and the model is used to tighten a downstream constraint-screening LP rather than to replace the optimizer itself [2212.00483]. In symbolic planning, the learned object is a shared action-cost function over a STRIPS action set such that observed plans become optimal under the induced planning model [2408.08343].

The term also has boundaries. CARMI is explicitly not a learned cost model in the modern sense of a predictive ML model trained to estimate cost; it is a cost-based optimizer for learned indexes built around a mostly handcrafted analytical model with entropy as a partition-quality metric [2103.00858]. That contrast is useful because it shows that the LCM label is most precise when the central mechanism is learned prediction of runtime, throughput, or objective value from features, rather than analytical scoring alone.

| Setting | Learned quantity | Decision role |
|---|---|---|
| Zero-shot database cost estimation | Query runtime [2201.00561] | Cost prediction on unseen databases |
| Cross-engine lakehouse optimization | Per-engine execution time [2506.02802] | Engine/provisioning routing |
| UDF-aware database optimization | Runtime of SQL queries with UDFs [2503.23863] | UDF pull-up/push-down decisions |
| Edge-cloud stream processing | \(T,L_p,L_e,R_O,S\) [2403.08444] | Initial operator placement |
| Reconfigurable dataflow compilation | Normalized throughput [2511.01872] | Placement scoring in compiler search |
| Unit commitment screening | \(J(\boldsymbol{\ell})\) [2212.00483] | Cost cap for LP screening |
| Classical planning | Shared action costs [2408.08343] | Make observed plans optimal |

## 2. Representations and model architectures

A recurrent property of LCM research is that the input is rarely flat SQL text alone. Recent models favor plan-aware trees or heterogeneous graphs that encode operator semantics, cardinality context, and sometimes resource structure. The zero-shot representation of Hilprecht et al. models physical plan operators together with predicates, tables, attributes, and output columns in a multi-typed graph; the explainability paper later emphasizes that graph-based LCMs such as the Zero-Shot cost model encode a query as a graph containing physical operators as well as additional nodes for predicates, join conditions, tables, and columns, and that explanations should therefore be produced over the actual graph input rather than a simplified tree [2201.00561][2507.14495].

Cross-engine SQL optimization adopts a heterogeneous graph derived from an optimized Substrait plan with five node types—Relation, Operation, Literal, Field, and Table—and processes it with a Bottom-up GNN. Each node type has a type-specific encoder MLP, message passing proceeds bottom-up, and the final query embedding is formed by mean pooling over Relation-node embeddings before multiple engine-specific predictor heads estimate runtimes [2506.02802]. Delta instead uses a plan-tree representation: each node carries a one-hot operator encoding, min-max normalized cardinality estimate, min-max normalized cost estimate, and a one-hot encoding sum of the relations involved in the rooted subplan. A tree-convolutional model with dynamic pooling then feeds dual heads that predict latency and heteroscedastic noise for Stage II plan selection [2506.15848].

When the plan contains opaque program code, the representation grows accordingly. GRACEFUL constructs a joint graph from the query plan and a UDF control-flow graph transformed into a DAG, with UDF node types `INV`, `COMP`, `BRANCH`, `LOOP`/`LOOP_END`, and `RET`. It also adds explicit links from query `COLUMN` nodes into the UDF and from the UDF `RET` node back to downstream plan nodes, so the learned estimator sees both relational context and UDF internal structure [2503.23863].

Placement-oriented LCMs extend the same principle to computation-plus-resource graphs. COSTREAM represents a streaming query as a joint graph containing operator nodes, hardware nodes, logical data-flow edges, and placement edges. Its message-passing order is deliberately asymmetric—operators \(\rightarrow\) hardware, hardware \(\rightarrow\) operators, and sources \(\rightarrow\) operators—to reflect contention, host capability, and workload propagation [2403.08444]. The compiler LCM for reconfigurable dataflow hardware likewise represents a candidate mapping as a graph \(G=(V,E)\) where nodes are actively used functional units and edges are used routes, with node embeddings \(X_v=[X_v^F,X_{O(v)}^O,X_{S(v)}^S]\) and route-aware edge embeddings processed by a GNN plus a 3-layer ReLU MLP regressor [2511.01872].

This suggests a broad structural pattern: LCMs are usually most effective when the representation mirrors the combinatorial object that the optimizer actually manipulates—plan trees, heterogeneous query graphs, query-plus-code graphs, or placed hardware graphs—rather than a database-agnostic bag of features.

## 3. Training regimes and data construction

The original learned database cost models were largely workload-driven: they required target-database executions and therefore high onboarding cost. Zero-shot cost models replace that regime with cross-database pre-training. In the zero-shot database benchmark, the model is trained over 20 databases with 15,000 queries per database and then applied to an unseen database without target-database runtime labels; few-shot fine-tuning with a small number of target queries further improves accuracy [2201.00561]. Cross-engine lakehouse optimization keeps the same transfer logic at engine level: the shared Bottom-up GNN is trained on five datasets with 5,000 generated queries per dataset, and few-shot adaptation or new-engine addition is done by updating only the predictor heads with 250 queries while keeping the shared embedding fixed [2506.02802].

A parallel line addresses the data bottleneck directly. The synthetic SQL bootstrapping work does not propose a new LCM architecture; it proposes a schema-specific SQL generation pipeline derived from DiGiT and inspired by self-instruct-style data generation. The pipeline creates connected subschemas, constructs few-shot prompts from CREATE statements and mechanically generated seed queries, validates generated SQL for syntax and relevance, analyzes coverage with Apache Calcite, and regenerates to fill gaps. For the downstream multi-head GNN-based LCM, training on 2,200 SDG-generated queries instead of 4,000 mechanically generated queries improves \(qmedian\) from 1.20 to 1.18, \(qmean\) from 1.41 to 1.34, and \(qp95\) from 2.38 to 2.37, while reducing training queries by 45% [2508.19807].

Other systems reuse optimization traces already produced upstream. Delta trains its Stage II cost model on the executed plan pool accumulated during Stage I value-network training, then augments that pool by extracting subplans and their direct runtimes. This expands the data by 8–9× more unique training samples on JOB and 2.5–4× on TPC-DS and Stack, which is one reason the paper characterizes Stage II training cost as negligible relative to value-network training [2506.15848]. GRACEFUL creates a dedicated benchmark for UDF-aware costing with 93.8k queries, 20 databases, and 142 hours of benchmark runtime; COSTREAM builds a benchmark of 43,281 query traces by executing streaming queries on heterogeneous hardware; and CLEO exploits recurring production workloads across 0.5 million jobs over four clusters to train about 25K specialized models in less than 45 minutes on a 200-node cluster [2503.23863][2403.08444][2002.12393].

The resulting lesson is data-centric. Several papers state, directly or indirectly, that LCM quality is constrained not only by architecture but by workload representativeness, coverage of bad as well as good alternatives, and the availability of labels that match the eventual optimization task.

## 4. Roles inside optimizers and execution systems

LCMs are used at very different points in decision pipelines. In cross-engine lakehouse systems, the role is direct routing: estimate execution time for each engine/provisioning in \(\mathcal{E}\) and choose the one with minimum predicted runtime [2506.02802]. In Delta, the role is narrower and explicitly second-stage: a value network performs Stage I beam search over partial plans to generate \(k=10\) complete candidates, and the learned cost model reranks those candidates in Stage II by predicted latency. A Mahalanobis-distance-based compatible query detector decides whether the learned planner should be trusted at all, routing incompatible queries to a fallback optimizer [2506.15848].

Production optimizer integration can be deeper. CLEO inserts learned exclusive-operator costing into the Cascades-style SCOPE optimizer at the Optimize Inputs stage, preserving the existing search architecture while replacing heuristic local cost estimation. It also extends the optimizer with resource-context, partition-exploration, and partition-optimization so that learned costs guide not only physical plan choice but also the number of partitions, hence the number of containers, during planning [2002.12393]. GRACEFUL augments a DBMS optimizer for plans with scalar Python UDFs: it enumerates pull-up and push-down alternatives for a UDF filter, varies assumed UDF-filter selectivity over \(\{0.1,0.3,0.5,0.7,0.9\}\), adjusts operator cardinalities above the UDF filter accordingly, and uses predicted plan runtimes under heuristics such as UBC, AuC, and Conservative to choose a placement. In evaluation, informed pull-up/push-down decisions can yield up to 50× speedups over the standard case where filter push-down is always applied [2503.23863].

Placement problems use LCMs as surrogate objectives. COSTREAM evaluates candidate placements of streaming operators onto heterogeneous edge-cloud hardware, filters candidates predicted to fail or exhibit backpressure, and then selects the placement that optimizes a target metric such as throughput or processing latency [2403.08444]. The hardware-mapping model for reconfigurable dataflow compilation replaces a hand-designed throughput heuristic in a simulated-annealing placer with a learned throughput predictor over mapped graphs; this yields 5.6% faster compiled graphs in the abstract’s summary and 5.7% higher throughput on BERT-large in the body [2511.01872].

Some systems use learned cost information more indirectly. In unit commitment, the neural network \(f_{NN}(\boldsymbol{\ell})\) predicts the optimal cost \(J(\boldsymbol{\ell})\) from load and contributes only a scalar upper bound \(\sum_i c_i x_i \le f_{NN}(\boldsymbol{\ell})(1+\epsilon)\) or \(\sum_i c_i x_i \le PGA(f_{NN}(\boldsymbol{\ell}))(1+\epsilon)\) to a screening LP, thereby shrinking the feasible region without replacing the final optimization [2212.00483]. In cost-aware LLM orchestration, xRouter is explicitly relevant but structurally different: it does not train a standalone supervised cost regressor, but a routing policy under the reward \(R_{\text{final}} = R_{\text{binary}} \times (K-\lambda C)\), so its learned object is a cost-sensitive orchestration policy rather than an explicit cost predictor [2510.08439].

## 5. Evaluation criteria, empirical limits, and controversy

LCM papers use several families of metrics, and they do not all measure the same property. Database runtime prediction papers predominantly report Q-error summaries such as \(qmed\), \(qmean\), and \(qp95\); zero-shot cost estimation, cross-engine routing, and synthetic-SQL bootstrapping all use these measures, with the standard interpretation that a median Q-error of 1.20 means half the predictions deviate by no more than 20% multiplicatively from the true runtime [2201.00561][2506.02802][2508.19807]. Delta supplements latency regression with workload-level metrics such as WRL and GMRL, while the hardware-mapping paper emphasizes relative error and Spearman rank correlation because ranking candidate placements is central inside simulated annealing [2506.15848][2511.01872]. CLEO evaluates prediction error and Pearson correlation, but also downstream latency and total processing time after actual re-optimization [2002.12393].

A central controversy in the field is that better point prediction does not automatically imply better optimizer decisions. The systematic study of seven state-of-the-art LCMs across join ordering, access path selection, and physical operator selection finds that the traditional PostgreSQL cost model often still outperforms LCMs in these tasks, even though LCMs typically achieve better raw prediction accuracy on held-out plans [2502.01229]. The paper’s explanation is multi-part: query optimization is a ranking-and-selection problem over candidate plans, not a single-plan regression problem; large underestimates on bad plans can create catastrophic false minima; training data is biased toward pre-optimized plans and truncated by timeouts; and some representations, notably MSCN-style SQL encodings, cannot even distinguish physical alternatives relevant to the decision. The same study also shows that hybrid models such as DACE and QPP-Net benefit strongly from using PostgreSQL cost as an input, which leads to the recommendation that future LCMs should build on expert cost signals rather than discard them outright [2502.01229].

Other empirical limits recur across domains. Zero-shot cost models depend on target-database statistics and benefit strongly from accurate cardinality estimates, with DeepDB outperforming optimizer cardinalities though the latter remain usable [2201.00561]. GRACEFUL’s UDF-aware estimator is highly accurate with actual or high-quality estimated cardinalities but deteriorates sharply with DuckDB optimizer cardinalities, showing that UDF runtime modeling is still bottlenecked by CE quality [2503.23863]. COSTREAM generalizes well to unseen placements, queries, and many hardware configurations, but extrapolation to unseen high network latencies is notably weaker than CPU or RAM extrapolation [2403.08444]. The synthetic SQL bootstrapping paper is explicit about synthetic-to-real distribution shift: schema-specific and validator-controlled SQL improves training efficiency, but synthetic workloads may still miss application semantics or temporal workload patterns [2508.19807].

This body of evidence suggests that the central empirical question for LCMs is not merely “how low is median Q-error,” but “under what data regime, representation, and optimizer interface does the learned model preserve the rankings that matter for actual decisions.”

## 6. Explainability, debugging, and open directions

As LCMs moved toward deep GNNs and tree models, a new problem emerged: accurate average predictions coexisted with large tail errors and little diagnostic visibility. “Opening The Black-Box: Explaining Learned Cost Models For Databases” presents the first approach focused specifically on explaining LCM predictions, with a local post-hoc notion of node importance over plan-graph nodes [2507.14495]. The paper adapts SensitivityAnalysis and GuidedBackprop from gradient-based XAI, GNNExplainer from graph classification to regression, and introduces DiffMask, where one node is masked, the prediction is recomputed, and importance is derived from the prediction difference. Because deleting nodes would invalidate the Zero-Shot graph structure, masking is implemented by zeroing the hidden state of the corresponding node rather than removing the node outright [2507.14495].

The explainability layer also introduces database-specific diagnostics. Node Ranking sorts nodes by decreasing importance; Runtime Correlation compares normalized runtime fractions to normalized importance fractions, with subplan runtimes subtracted to isolate local operator contribution; and Explanation Quality adapts Fidelity+, Fidelity-, and CharacterizationScore to regression, scaling all metrics to \([0,1]\) [2507.14495]. In the demo, the interface shows SQL text, graph representation, predicted runtime, actual runtime, Q-error, and colorized node views for either importance or actual runtimes across workloads such as IMDB, TPC-H, Baseball, and synthetic workloads [2507.14495].

The empirical findings from explainability are themselves substantive. The authors often observe high correlation between node importance and actual runtimes, which suggests the explanations capture meaningful internal behavior, but they also observe cases where predictions are accurate even though the importance pattern does not match actual runtimes. Their interpretation is that a model can be right for the wrong reasons, and such mismatches should still be corrected for robust generalization. A recurring pattern is that aggregation nodes are often assigned high importance despite not accounting for much actual runtime, suggesting operator-specific blind spots or feature imbalance in the model [2507.14495].

Several future directions follow directly from the current literature. Delta argues that LCMs are most effective as accurate second-stage rerankers over a narrowed candidate set rather than as the sole search mechanism over an \(O(n!)\) plan space, which points toward increasingly hybrid planners [2506.15848]. The cross-engine optimizer suggests extending from query-level runtime prediction toward node-level costs and distributed execution optimizers [2506.02802]. COSTREAM explicitly mentions operator reordering and degree-of-parallelism selection as extensions beyond initial placement [2403.08444]. Zero-shot cost modeling frames few-shot adaptation as a practical remedy for workload drift and unseen join patterns [2201.00561]. Explainability work identifies feature importance and subgraph importance as next steps beyond node importance [2507.14495]. A plausible implication is that future LCM research will be defined less by a single architecture and more by the joint treatment of transfer, hybridization, uncertainty, decision-aware evaluation, and debuggability.

Source: https://www.emergentmind.com/topics/learned-cost-models-lcms