Cardinality estimation is essential for query optimization, but most existing learned estimators focus on a single predicate type, such as string LIKE clauses or numerical range filters. In practice, analytical workloads often combine both types, while the accuracy of string estimators tends to decrease with longer patterns. We introduce MultiCard, a comprehensive learned cardinality estimator that unifies LIKE predicates and numerical filters within a single end-to-end architecture. By combining a Transformer for long-range sparse patterns with an LSTM for short, frequent patterns, MultiCard achieves robust pattern modeling. In parallel, a numerical encoder integrates catalog histograms and structural predicate features, enabling the model to dynamically assess histogram estimation accuracy across different operators and data skew conditions. A final Transformer layer captures interactions among heterogeneous predicates before a multilayer perceptron predicts query cardinalities. We also introduce UPCI, a workload generator that produces length-balanced LIKE patterns, multi-column numerical predicates, and exact cardinality labels for training and evaluation. Experiments on five real-world datasets show that, for string-only workloads, MultiCard achieves the best or near-best Q-error across all datasets compared with state-of-the-art methods. For mixed multi-attribute queries, MultiCard reduces PostgreSQL's mean Q-error by up to 16 times while maintaining an inference latency below 5 ms.
Figures & tables
Figure 1: The architecture of MultiCard. First, the string predicate is processed by an embedding layer to generate a dense vector representation. This vector is then passed to the String Predicate Encoder block, which combines a Transformer to capture long-range textual dependencies and an LSTM to handle shorter patterns. Simultaneously, numerical predicates are transformed into representation vectors and combined with histogram data through a dedicated numerical embedder. Finally, these three feature vectors are fused using a Transformer layer to learn their cross-feature interactions, and a Multi-Layer Perceptron (MLP) outputs the final cardinality estimation.
Criterion
Trad.
Query-Driven
Data-Driven
Hybrid
Estimation Accuracy
L
M
M
H
Data Dependency Awareness
L
L
H
H
Query Workload Awareness
N
H
N
H
Training Cost
N
M
M-H
H
Inference Latency
L
L
H
L
Memory
L
M-H
M
H
Table 1: Qualitative comparison of cardinality estimation paradigms across key evaluation criteria.
Query Category
Description
Example Pattern
Exact Query
Matches the complete literal string
Still Orangutans
Prefix Query
Matches strings starting with specific text
Sti%
Suffix Query
Matches strings ending with specific text
%Orangutans
Substring Query
Matches strings containing specific text
S%Oran%
Positional Query
Matches strings with specific character counts
Sti_l_Oran_utan_
Complex Combination
Any mixed usage of % and _ wildcards
%ill_Or%ta_s
Table 2: Type Of Strings (LIKE Patterns) Supported By SPE
String Set in a Table
Integer Set in a Table
Dataset
∣Σ∣
|SD|
AVG Length
MAX Length
MIN Value
MAX Value
#Columns
DBLP
73
2,365,100
14.2
62
1
2,365,100
2
WIKI
3735
1,031,930
98.4
300
__
__
__
IMDB
81
1,000,000
19.2
278
0
2,525,672
7
TPCH
26
200,000
32.75
50
1
200,000
3
Ergastf1
30
840
7.1
18
1
841
2
Table 3: Dataset statistics
Method
Query-driven
Data-driven
Hybrid
CLIQUE
✓
DREAM
✓
LPLM
✓
SPE (ours)
✓
PostgreSQL
✓
MultiCard (ours)
✓
Table 4: Classification of the methods considered in this paper.
Q-ERROR
Datasets
Methods
50th
95th
99th
AVG
MAX
Inference Time (ms)
#Params
CLIQUE
1.27
3.58
12.1
2.58
9895.44
1.72
2.42M
DREAM
1.35
4.27
15.19
2.4
1487.82
1.61
2.43M
PostgreSQL
14.33
43
145.96
24.19
51591.35
0.08
—
WIKI-S
LPLM
2
18.24
27
5.2
10876.6
4.62
2.44M
SPE (ours)
1.25
3.54
12
2.52
9895
1.53
2.84M
Table 5: Comparative analysis of SPE and existing baselines on LIKE pattern (single-attribute) queries. (The best results are highlighted in dark green, while the second-best results are highlighted in light green)
Q-ERROR
Datasets
Methods
50th
95th
99th
AVG
MAX
Inference Time (ms)
#Params
Sampling 0.1%
3
214.00
853.00
44.96
4791.00
0.21
—
Sampling 1%
2.00
45.00
108.00
9.43
524.00
0.68
—
PostgreSQL
3
35
153.7
10.51
1838.5
0.37
—
IMDB-M
MultiCard
1.03
1.64
2.65
1.15
67.7
4.47
1.62M
Sampling 0.1%
6.00
406.00
1267.00
79.07
8500.00
0.56
—
Table 6: Comparative analysis of MultiCard and existing baselines on LIKE pattern and numerical predicate (multi-attribute) queries. (The best results are highlighted in dark green, while the second-best results are highlighted in light green.)
Q-ERROR
Datasets
Training Ratio
50th
95th
99th
AVG
MAX
10%
1.16
2.38
4.43
1.42
274.9
50%
1.05
1.78
2.94
1.2
505.3
80%
1.06
1.72
2.66
1.18
41.5
IMDB-M
100%
1.03
1.64
2.65
1.15
67.7
10%
1.65
6.13
17.1
2.97
1601.1
Table 7: Impact of training data volume on Q-error of MultiCard across datasets.
Figure 2: Average Q-error vs. string length on four datasets.
End-to-End Execution Time (ms)
Datasets
Methods
50th
95th
99th
AVG
MAX
CLIQUE
501.14
808.29
1731.59
474.75
3197.17
DREAM
501.46
810.72
1731.63
474.70
2955.83
PostgreSQL
502.52
821.26
1798.08
479.74
2973.87
LPLM
500.23
810.89
1662.26
474.97
3011.42
SPE (ours)
497.61
804.75
1583.18
469.51
2959.90
Table 8: End-to-end execution time for single-attribute queries. (The best results are highlighted in dark green, while the second-best results are highlighted in light green)
End-to-End Execution Time(ms)
Datasets
Model
50th
95th
99th
AVG
MAX
MultiCard
92.97
192.25
215.78
98.26
249.71
PostgreSQL
93.25
192.61
216.09
98.55
250.02
IMDB-M
True Card
93.04
192.49
215.59
98.40
249.78
MultiCard
382.36
681.74
740.54
363.61
876.65
PostgreSQL
364.60
683.57
743.35
364.60
876.87
Table 9: End-to-end execution time for multi-attribute queries
Query optimization of Basic Graph Patterns (BGP) SPARQL queries over Knowledge Graphs (KG) requires accurate cardinality estimation. Recently published learned estimators outperform statistics- and sampling-based approaches, but share a limitation preventing their adoption in real-world triplestores: they are transductive and require retraining when the underlying graph changes or when applied to new graphs. We present FICE (Fully Inductive Cardinality Estimation), the first learned cardinality estimator for BGP queries over KGs that generalizes to entirely unseen graphs (including unseen relations), without any retraining. FICE is a graph neural network (GNN) with two coupled components. First, an encoder GNN over a factor-graph view of the KG produces entity and relation embeddings. We prove that BGP cardinality is a local function of the 2-hop neighborhood around bound terms in this view, motivating the local message-passing encoder. A decoder GNN then composes these embeddings along the join topology of the query to predict log-cardinality. The encoder and decoder are trained jointly, making the embeddings specialized for cardinality estimation. FICE is trained using neighborhood sampling to scale to KGs with millions of triples, and decouples embedding generation from cardinality decoding to enable estimation latency below a millisecond. Compared to learned and non-learned baselines over 10 KGs, FICE reduces the overall median q-error from 13.54 (for the best competitor) to 5.34 and dominates all approaches in tail behavior.
In-database predictive query processing increasingly applies Transformer-based models within relational pipelines. However, existing in-database inference typically exposes only tuple-level model inputs to the inference runtime, leaving relational predicates and metadata statistics invisible to neural execution planning. In this paper, we propose QCATS, a query context-aware transformer slicing framework that enables efficient sparse inference inside database systems. QCATS executes at query granularity: instead of routing individual tokens or tuples during inference, it uses query predicates and metadata statistics to pre-select context-aligned FFN slices before model execution. The framework comprises offline expert construction and lightweight query-level routing that dynamically selects experts during execution. QCATS further introduces system optimizations, including asynchronous CPU-GPU pipelines and routing-aware batching. Experiments on four predictive-query workloads with BERT-base and Qwen-0.6B show that QCATS achieves up to 4.42x latency reduction while preserving prediction accuracy comparable to dense baselines.
Yueying Li, Zhongle Xie, Ke Chen +1
The State Key Laboratory of Blockchain and Data Security, Zhejiang University · Hangzhou High-Tech Zone (Binjiang) Institute of Blockchain and Data Security
Cardinality-estimation (CE) research ranks estimators by q-error, yet it is well known that q-error is an imperfect proxy for query-plan quality. We give a measurement-driven account of when it is a good proxy and when it is not, and why. Modeling plan selection as an argmin over a piecewise-linear cost landscape, we find that plan regret (the cost of the chosen plan relative to the optimal, under true cardinalities) is governed by plan-cost geometry in a regime-dependent way. (i) For small errors, a true-point condition number kappa predicts regret and out-predicts q-error; its predictive power decays to zero as error grows, as a local linearization must. (ii) For large errors -- where deployed learned estimators operate -- an estimator-independent average-case sub-optimality measure ACS-infinity predicts which queries are regret-prone (Spearman rho ~ 0.54 on STATS-CEB), while q-error is nearly uninformative at the query level (rho ~ 0.05). (iii) The worst case is Haritsa's maximum sub-optimality (MSO). The three are one cost-ratio spectrum under three weightings. We prove a limit law ACS-infinity = sum_k r_k pi_k with cardinality-independent combinatorial weights, and validate every claim on STATS-CEB and JOB-light with four released estimators under pre-registered decision rules, and confirm on real PostgreSQL runtime that ACS-infinity predicts regret where q-error does not. The contribution is conceptual and empirical -- an average-case companion to worst-case robust query optimization, and a characterization of when an accuracy metric tracks plan quality -- rather than a new estimator. Code and the full pre-registration are public.