# Flow-Loss: Learning Cardinality Estimates That Matter

arXiv: https://arxiv.org/abs/2101.04964 · HTML: https://mlsanity.com/paper/2101.04964/

## Key facts

- Cited by 22 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 13 Jan 2021.

## Built on by (most cited first, 22 of 22)

- [Cardinality Estimation in DBMS: A Comprehensive Benchmark Evaluation](https://mlsanity.com/paper/2109.05877/) (2021)
- [FactorJoin: A New Cardinality Estimation Framework for Join Queries](https://mlsanity.com/paper/2212.05526/) (2022)
- [A Unified Transferable Model for ML-Enhanced DBMS](https://mlsanity.com/paper/2105.02418/) (2021)
- [E2ETune: End-to-End Knob Tuning via Fine-tuned Generative Language Model](https://mlsanity.com/paper/2404.11581/) (2024)
- [CardBench: A Benchmark for Learned Cardinality Estimation in Relational Databases](https://mlsanity.com/paper/2408.16170/) (2024)
- [The Unreasonable Effectiveness of LLMs for Query Optimization](https://mlsanity.com/paper/2411.02862/) (2024)
- [Theoretical Analysis of Learned Database Operations under Distribution Shift through Distribution Learnability](https://mlsanity.com/paper/2411.06241/) (2024)
- [Kepler: Robust Learning for Faster Parametric Query Optimization](https://mlsanity.com/paper/2306.06798/) (2023)
- [A Practical Theory of Generalization in Selectivity Learning](https://mlsanity.com/paper/2409.07014/) (2024)
- [HERO: Hint-Based Efficient and Reliable Query Optimizer](https://mlsanity.com/paper/2412.02372/) (2024)
- [In-Context Adaptation to Concept Drift for Learned Database Operations](https://mlsanity.com/paper/2505.04404/) (2025)
- [Learned-Database Systems Security](https://mlsanity.com/paper/2212.10318/) (2022)
- [Towards Establishing Guaranteed Error for Learned Database Operations](https://mlsanity.com/paper/2411.06243/) (2024)
- [Robust Plan Evaluation based on Approximate Probabilistic Machine Learning](https://mlsanity.com/paper/2401.15210/) (2024)
- [Large Scale Multi-Task Bayesian Optimization with Large Language Models](https://mlsanity.com/paper/2503.08131/) (2025)
- [Data-Agnostic Cardinality Learning from Imperfect Workloads](https://mlsanity.com/paper/2506.16007/) (2025)
- [When Does q-error Predict Plan Regret? Three Regimes of Cardinality-Estimation Error](https://mlsanity.com/paper/2606.15600/) (2026)
- [Reqo: A Comprehensive Learning-Based Cost Model for Robust and Explainable Query Optimization](https://mlsanity.com/paper/2501.17414/) (2025)
- [Low Rank Learning for Offline Query Optimization](https://mlsanity.com/paper/2504.06399/) (2025)
- [ZeroCard: Cardinality Estimation with Zero Dependence on Target Databases -- No Data, No Query, No Retraining](https://mlsanity.com/paper/2510.07983/) (2025)
- [CoLSE: A Lightweight and Robust Hybrid Learned Model for Single-Table Cardinality Estimation using Joint CDF](https://mlsanity.com/paper/2512.12624/) (2025)
- [Fully Inductive Cardinality Estimation](https://mlsanity.com/paper/2607.28311/) (2026)

## Abstract (arXiv)

Previous approaches to learned cardinality estimation have focused on improving average estimation error, but not all estimates matter equally. Since learned models inevitably make mistakes, the goal should be to improve the estimates that make the biggest difference to an optimizer. We introduce a new loss function, Flow-Loss, that explicitly optimizes for better query plans by approximating the optimizer's cost model and dynamic programming search algorithm with analytical functions. At the heart of Flow-Loss is a reduction of query optimization to a flow routing problem on a certain plan graph in which paths correspond to different query plans. To evaluate our approach, we introduce the Cardinality Estimation Benchmark, which contains the ground truth cardinalities for sub-plans of over 16K queries from 21 templates with up to 15 joins. We show that across different architectures and databases, a model trained with Flow-Loss improves the cost of plans (using the PostgreSQL cost model) and query runtimes despite having worse estimation accuracy than a model trained with Q-Error. When the test set queries closely match the training queries, both models improve performance significantly over PostgreSQL and are close to the optimal performance (using true cardinalities). However, the Q-Error trained model degrades significantly when evaluated on queries that are slightly different (e.g., similar but not identical query templates), while the Flow-Loss trained model generalizes better to such situations. For example, the Flow-Loss model achieves up to 1.5x better runtimes on unseen templates compared to the Q-Error model, despite leveraging the same model architecture and training data.