Pith. sign in

REVIEW 4 major objections 5 minor 39 references

ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Pith's one-line read ScaleSense claims that choosing a query's compute units should be driven by quantile forecasts of four physical resource bottlenecks rather than by a point latency estimate.

desk verdict A serious industrial scaling paper whose Factor-Informed Hurwicz controller is genuinely new and whose production evaluation is large, but the headline CSA gains rest on a single-plan assumption the paper never validates. read the letter →

arxiv 2608.07945 v1 pith:2GFAFI2Y submitted 2026-08-08 cs.DB cs.AIcs.DC

classification cs.DBcs.AIcs.DC
keywords serverlessdatawarehouseauto-scalingresourceestimationquantileregressionqueryplanencodinggraphtransformerperformance-costtrade-offAnalyticDB
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

ScaleSense is a framework for deciding, for each ad-hoc query in a serverless data warehouse, how many Compute Units (CUs) to allocate before the query runs. It claims that the right basis for this decision is not a single predicted latency but a set of quantile forecasts for four physical bottlenecks—CPU time, peak memory, table scan volume, and shuffle size—conditioned on each candidate configuration, together with a latency interval derived from them. An auto-scaling controller then blends the optimistic and pessimistic latency bounds adaptively, using the predicted resource pressure as a risk signal, so the chosen configuration respects user-defined cost and performance constraints. The paper reports that on 1.36 million production queries and TPC-DS, this yields a 76.7% relative improvement in constraint-satisfying configuration selection over the best baseline, with up to a 5.22x monetary cost reduction under the performance-optimization policy. If correct, this replaces reactive over-provisioning with proactive, preference-aware allocation.

What carries the argument

Three components carry the argument. (1) Multi-faceted Query Encoder: a Graph Transformer with Laplacian positional encoding on the plan DAG, chunked by plan-tree summarization (200-node chunks) when plans are large, produces a 64-dimensional plan embedding that is concatenated with 157 plan-statistic features, giving a 221-dimensional query representation. (2) Quantile Resource Predictor: Stage 1 gradient-boosted quantile regression predicts Q10, Q50, and Q90 for CPU time, peak memory, table scan volume, and shuffle size, with monotonicity clipping and a zero-inflated hurdle classifier for sparse dimensions; Stage 2 learns latency quantiles from these factor quantiles. (3) Factor-Informed Hurwicz Criterion: the controller combines a resource-pressure signal, based on predicted per-CU memory and CPU load, and a factor-position signal, based on where the median sits inside each prediction interval, into an adaptive optimism parameter that blends Q10 and Q90 latency before solving the user's constrained minimization over candidate CU sets.

What would settle it

Run a sample of TPC-DS queries at 16 and 512 CUs, capture the optimizer's physical plans at each size, and compare the DAGs: if join orders, exchange placement, or operator choices differ materially between configurations, or if actual cardinalities fall outside the predictor's stated intervals, then ScaleSense's forecasts are for a plan that would not run, which would contradict the assumption that one plan supports all candidates. Comparing predicted versus actual CPU, memory, disk, and network footprints under re-optimized plans would settle the claim directly.

Watch

Extended reading notes

Core claim

At the paper's center is a two-stage learned predictor. Stage 1 estimates, for each candidate CU configuration, the 10th, 50th, and 90th percentiles of CPU time, peak memory, table scan volume, and shuffle size, using XGBoost quantile regression on a 221-dimensional feature vector built from a Graph Transformer plan embedding and plan statistics; a zero-inflated hurdle classifier handles the large fraction of exact-zero I/O and memory values. Stage 2 predicts latency quantiles from those factor quantiles plus features, so the controller receives calibrated uncertainty rather than a point estimate. The Factor-Informed Hurwicz Criterion then chooses the configuration by interpolating Q10 and Q90 latency with a per-configuration weight derived from resource pressure (predicted Q90 memory and CPU per CU) and from the skewness of the factor prediction intervals. The claim is that this uncertainty-aware pipeline selects configurations satisfying both latency and cost constraints far more often than point-estimate baselines: average constraint satisfaction accuracy improves by 27.2 percentage points, and the gain is attributable mainly to the controller rather than to the encoder.

Load-bearing premise

The load-bearing premise is that the physical query plan and the optimizer's row and cardinality estimates stay valid for every candidate CU configuration, so one plan per query can predict resource use at 16, 64, and 512 CUs alike.

Editorial extensions

If this is right

  • Users can shift between performance-optimization and cost-optimization policies by changing two parameters, epsilon and rho, without retraining the predictor.
  • I/O-bound or network-bound queries will not be blindly given more CUs, because the predictor identifies the bottleneck dimension that scaling cannot remove.
  • Memory-sensitive queries get conservative allocations because the Q90 memory bound is used as a safety guardrail against OOM.
  • The framework's relative ranking across candidate configurations matters more than absolute accuracy, so out-of-distribution robustness can be evaluated on benchmarks like TPC-DS.
  • Inference overhead below 1% of query execution time makes per-query decisions feasible in the critical path.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Going beyond the paper: because the predictor is trained on one physical plan per query, the approach would need re-validation in settings where the optimizer re-optimizes the plan as the CU allocation changes; a testable extension is comparing predicted footprints against actual execution under plan changes.
  • Going beyond the paper: the same quantile-then-controller pattern could transfer to other serverless SQL systems with standardized compute units, such as Redshift RPUs or Snowflake warehouses, as long as execution logs expose the four physical counters.
  • Going beyond the paper: the prediction intervals themselves could serve as admission-control signals, not just scaling signals; a query whose Q90 memory exceeds the largest candidate configuration could be flagged before scheduling.
  • Going beyond the paper: a natural stress test is to measure whether the 27.2 percentage point gain persists when candidate configurations are not a small discrete ladder but a continuous range, since the controller's pressure signal normalizes across candidates.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents ScaleSense, a per-query auto-scaling framework for Alibaba AnalyticDB. It encodes optimizer physical plan DAGs with a graph transformer and plan-tree summarization, predicts quantiles (Q10, Q50, Q90) of CPU time, peak memory, disk scan volume, shuffle size, and end-to-end latency via a two-stage XGBoost quantile regression model with zero-inflated handling, and then selects a CU configuration with a Factor-Informed Hurwicz (FIHC) controller that blends optimistic and pessimistic latency estimates using resource-pressure and interval-position signals. The evaluation uses two production datasets (D1, D2) for prediction accuracy and the TPC-DS 1TB benchmark for auto-scaling. The abstract claims a 76.7% relative improvement in constraint satisfaction accuracy (CSA) over the best baseline and up to 5.22x monetary cost reduction under the performance-optimization policy.

Significance. If the results are robust, the work is significant: it targets a real industrial problem (per-query resource provisioning in serverless data warehouses), uses large-scale production data, and introduces an uncertainty-aware controller that goes beyond point-estimate scaling. The strengths are the explicit multi-dimensional resource prediction, the quantile interval framework, the zero-inflated classifier for sparse targets, and the low reported inference overhead. These are useful contributions to the learned resource estimation and auto-scaling literature. However, the central auto-scaling claim rests on a single-plan assumption that is not validated, and the CSA results are reported without variance or significance testing on a small benchmark (99 queries). The paper also acknowledges in Section 7 that counterfactual ground truth across CU configurations was not collected, which further limits the strength of the end-to-end claim.

major comments (4)
  1. [Section 4.1, 4.3, and Problem 1] The auto-scaling evaluation assumes that the optimizer's physical plan DAG is invariant to the CU configuration. Problem 1 defines f(q, a) with a single plan embedding z, Algorithm 1 chunks that same plan for all candidates, and Section 4.3 varies only the CU-valued feature when scoring configurations. However, physical plans can change with resources (join orders, exchange distributions, memory-driven spill behavior), and the paper never records whether the plan DAG used for prediction is the plan that would actually run under each candidate CU. Table 1 shows resource footprints changing with scale, but it does not show plan DAG differences. Section 7's Lesson 1 explicitly states that full replay across CU configurations was infeasible, so no evidence of plan stability is provided. Since the FIHC pressure and position signals are computed from Stage 1 predictions on those plans, a plan change would propagate into the recommendation and could make the reported 76.7% CSA improvement an artifact of scoring plans that would not execute. This is a load-bearing gap for the paper's main claim.
  2. [Section 5.3] The CSA results are reported on only the 99 TPC-DS queries, with no repeated train/test splits, no confidence intervals, and no significance tests. The average improvement of 27.2 pp over the best baseline is the mean over six hand-picked constraint settings; given the small test set and the variance visible in Figures 9 and 10, this difference may be within noise. Similarly, the 'up to 5.22x' cost reduction is a maximum over individual queries, not a typical or average outcome, and the paper presents it without a confidence estimate. The paper should provide per-setting results with repeated evaluation, or at least bootstrap intervals, to support the quantitative headline claim.
  3. [Section 5.3, FIHC alpha assignment] The FIHC controller's alpha parameter is assigned by a heuristic threshold: alpha=0 for performance-optimization policies and alpha=1 for cost-optimization policies, based on a threshold of 5 on the sum of user scaling ratios. This assignment is not derived from the optimization problem and no sensitivity analysis is given. Because the paper attributes the majority of the CSA gain to FIHC (+27.1 pp over SS-naive), the result is contingent on this hand-chosen mapping. The paper should either provide a principled way to set alpha from user preferences, or report how CSA varies with alpha to show the gain is not a tuning artifact.
  4. [Table 2] The claim that the quantile prediction acts as a 'reliable safety net' is weakened by under-coverage on the most safety-critical dimension. On D1, the 80% prediction interval for peak memory achieves only 68.03% coverage, which is well below the nominal 80%. Since memory under-estimation is the most catastrophic failure mode (OOM), the paper should discuss the calibration gap, consider wider intervals or conformal calibration for memory, and explain why the current coverage is acceptable for production deployment.
minor comments (5)
  1. [Abstract and Section 5.1] The abstract states 'Evaluations on over 1.36 million production queries,' but the auto-scaling evaluation is performed only on TPC-DS 1TB (99 queries); the production datasets D1 and D2 are used for prediction accuracy, not for end-to-end scaling. Please clarify this distinction in the abstract and introduction.
  2. [Section 5.2, Figure 8] The relative Q-error plots would be more informative if accompanied by absolute Q-error values or a table, and if error bars or significance markers were included. The text reports improvements like '1.6%' and '5.1%' for latency and CPU, which are small; the presentation should make clear which differences are practically meaningful.
  3. [Section 4.1, Algorithm 1] The complexity analysis states that the full-plan Laplacian eigen-decomposition costs O(N^3), then claims the summarization reduces this to linear in N for fixed C. This is correct only if the eigen-decomposition is the dominant cost and the chunk size C is constant; please state the assumption about the sparsity of the plan DAG and the cost of eigen-decomposition for the typical plan sizes encountered.
  4. [References] Reference [5] is listed as 'The SafeLoad authors' with a GitHub URL, which is not a proper citation. This should be replaced with a concrete author list and venue, or merged with the SafeLoad citation [33].
  5. [Section 2.1] The text says each CU is 'one CPU core paired with 4GB of main memory' and later that each CU is 'provisioned as an isolated lightweight VM.' These statements are not obviously consistent; please clarify whether a CU is a VM or a resource unit within a VM, as this affects the resource pressure signal definition.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: headline results are judged against measured TPC-DS executions and production logs, not against ScaleSense's own predictions.

full rationale

ScaleSense's derivation chain is self-contained with respect to its central claims. The resource and latency predictors (Eqs. 4-6) are trained with pinball loss on empirically measured labels, as stated in Section 4.2: "all training labels are empirically acquired directly from query execution logs," so the predicted CPU, memory, disk, network, and latency values are not defined in terms of the scaling objective. The auto-scaling evaluation in Section 5.3 scores CU recommendations against measured TPC-DS speedup and cost thresholds rather than against the model's own predictions, which means the 76.7% CSA improvement and 5.22x cost reduction are not self-referential. The FIHC controller's adaptive blending (Eqs. 8-13) is a decision rule over predicted quantiles, and its contribution is isolated by the SS-naive ablation using measured CSA outcomes; the alpha assignment is a stated policy heuristic, not a fitted parameter renamed as a prediction. The reuse of SafeLoad's 157-dimensional feature set [33] and the Graph Transformer/XGBoost settings [18,33] cites published, externally usable artifacts, and no uniqueness theorem or unverified self-citation is invoked to forbid alternative designs. The single-plan assumption identified in Section 4.1 and Problem 1 is a genuine robustness threat, but it concerns correctness under possible plan changes rather than equivalence of output to input by construction; therefore no circular step is exhibited.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim rests on domain assumptions about which resource counters are sufficient, plan stability across CU configurations, and the validity of XGBoost quantile predictions. No new physical entities are introduced; the new components, such as the Factor-Informed Hurwicz criterion, are algorithmic constructions. The free parameters are dominated by hand-chosen hyperparameters and controller weights, none of which are ablated or calibrated.

free parameters (6)
  • FIHC alpha assignment = alpha=0 for PO, alpha=1 for CO, threshold 5
    Section 5.3 assigns alpha based on whether the sum of user scaling ratios exceeds a heuristic threshold of 5. This directly changes the selected CU and is not sensitivity-tested.
  • Plan chunk size C = 200 operator nodes
    Section 4.1 and Section 5.1 state the chunk budget is empirically determined from AnalyticDB production statistics, with no ablation across values.
  • Graph Transformer hyperparameters = 8 LPE eigenvectors, 2 layers, hidden 64, 4 heads
    Section 5.1 adopts these from prior work [18]; they control the quality of the plan embedding but are not tuned or varied here.
  • XGBoost hyperparameters = max_depth=10, learning rate=0.03, subsample=0.8, colsample=0.8
    Section 5.1 adopts these from SafeLoad [33] for both Stage 1 and Stage 2 quantile regressors.
  • Quantile levels and 80% interval = 0.1, 0.5, 0.9
    Section 4.2 chooses these quantiles based on the empirical analysis in Section 3. Coverage on D1 memory is only 68%, so the nominal 80% interval is not consistently calibrated.
  • FIHC weighting scheme = lambda = alpha * pressure + (1-alpha) * position; pressure = 1 - 0.5*(p_mem + p_cpu)
    Section 4.3, Eqs. 8-11: the functional form and the equal weighting of memory and CPU pressure are hand-crafted; no ablation varies these weights.
assumptions (5)
  • domain assumption The four measured physical footprints, CPU time, peak memory, table scan volume, and shuffle size, are sufficient bottleneck indicators for end-to-end query latency across candidate CU configurations, and execution logs provide accurate ground-truth labels for them.
    Invoked in Section 3 (Insight 1) and Section 4.2 when defining the five prediction targets; if a bottleneck is not captured by these four counters, the latency predictor has no path to see it.
  • domain assumption The optimizer-generated physical plan DAG for a query remains representative across all candidate CU configurations, so one plan encoding can be scored at 16, 64, and 512 CUs.
    Section 4.1 and Problem 1 encode a single plan plus the CU value; plan changes across resource scales or stale optimizer statistics would invalidate the per-configuration predictions.
  • standard math The normalized graph Laplacian eigenvectors provide useful positional encodings for query-plan DAGs, and a suffix chunking scheme preserves enough local topology for large plans.
    Section 4.1 and Algorithm 1; this is standard spectral graph theory and a common GNN practice, though its effectiveness for query plans is an empirical claim from [18].
  • domain assumption XGBoost quantile regression on log-transformed targets, with monotonicity clipping at inference, produces valid quantile estimates for all five targets.
    Section 4.2, Eqs. 4-5; no conformal calibration is applied, and the paper itself notes XGBoost extrapolates conservatively outside the training range.
  • ad hoc to paper ScaleSense assigns alpha=0 for performance-optimization policies and alpha=1 for cost-optimization policies based on a heuristic threshold of 5 on the sum of user scaling ratios.
    Section 5.3; this hand-chosen rule determines the FIHC blend and is not derived or sensitivity-tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB." pith.science (2026). https://pith.science/paper/2GFAFI2Y

@misc{pith2026260807945,
  author       = {Pith},
  title        = {Pith review of: ScaleSense: Cost-Intelligent Scaling Framework via Learned Resource Estimation in Alibaba AnalyticDB},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2GFAFI2Y}},
  note         = {Machine review of arXiv:2608.07945}
}
read the original abstract

Cloud-native serverless data warehouses achieve fine-grained elasticity by decoupling storage from compute, yet determining the optimal resource allocation for highly heterogeneous ad-hoc queries remains a formidable industrial challenge. Our analysis of production workloads in Alibaba AnalyticDB exposes a costly ``provisioning trap'': the fear of catastrophic resource depletion drives users to blindly over-provision resources, wasting immense monetary budgets without alleviating non-CPU bottlenecks (e.g., I/O saturation). To break this impasse, we propose ScaleSense, a proactive, query-level resource scaling framework. Specifically, it features a multi-faceted query encoder that jointly models plan topologies and hardware specifications. Crucially, a quantile-based resource predictor estimates multi-dimensional physical footprints, acting as a reliable safety net for optimal resource scaling. An auto-scaling controller then navigates the performance-cost Pareto frontier, dynamically tailoring allocations to specific business priorities without requiring model retraining. Evaluations on over 1.36 million production queries show that ScaleSense achieves state-of-the-art prediction accuracy with good prediction interval coverage. By achieving a 76.7% relative improvement in optimal resource configuration selection over the best baseline, this approach addresses the critical performance-cost trade-off while maintaining low-overhead inference latency, confirming its practical performance in production deployments. Under the performance-optimization policy, ScaleSense satisfies user-defined performance requirements while reducing monetary cost by up to 5.22x.

Figures

Figures reproduced from arXiv: 2608.07945 by the authors.

Figure 1
Figure 1. The role of ScaleSense. The emergence of cloud-native serverless architectures, exempli￾fied by prominent systems such as Snowflake [10], Amazon Redshift [4], and Alibaba Cloud AnalyticDB [8], has transformed data man￾agement by leveraging storage-compute disaggregation to achieve fine-grained elasticity. In these environments, fixed-size clusters are replaced by elastic compute pools that can scale dynamically doi:… view at source ↗
Figure 2
Figure 2. The architecture of AnalyticDB, highlighting [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Latency distribution of TPC-DS 1 TB queries across six CU configurations (16, 32, 64, 128, 256, and 512 CUs). [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Quantile distribution of query latency and key factors across the CPU, memory, disk I/O, and network dimensions. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 6
Figure 6. Figure 6: Architecture of the Multi-faceted Query Encoder. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Architecture of the Quantile Resource Predictor. [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Relative Q-Error of methods compared to the best baseline (lower is better) on the real production datasets D1 and D2. [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Performance optimization (base CUs = 16 CUs). [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: Cost optimization (base CUs = 128 CUs). on average, respectively. These results show that the controller gain does not come from choosing a single conservative or optim￾istic quantile; it comes from factor-informed adaptation between quantiles according to policy sema…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 34 canonical work pages

  1. [1]

    Alibaba Cloud. 2026. AnalyticDB Compute Unit (ACU) Terms and Defin- itions. https://help.aliyun.com/en/analyticdb/analyticdb-for-mysql/product- overview/terms. Accessed: 2026-03-02

  2. [2]

    Omid Alipourfard, Hongqiang Harry Liu, Jianshu Chen, Shivaram Venkataraman, Minlan Yu, and Ming Zhang. 2017. Cherrypick: adaptively unearthing the best cloud configurations for big data analytics. InProceedings of the 14th USENIX Conference on Networked Systems Design and Implementation(Boston, MA, USA) (NSDI’17). USENIX Association, USA, 469–482

  3. [3]

    Amazon Web Services. 2026. Amazon Redshift Serverless Capacity and RPUs. https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-capacity.html. Ac- cessed: 2026-03-02

  4. [4]

    Nikos Armenatzoglou, Sanuj Basu, Naga Bhanoori, Mengchu Cai, Naresh Chain- ani, Kiran Chinta, Venkatraman Govindaraju, Todd J. Green, Monish Gupta, Sebastian Hillig, Eric Hotinger, Yan Leshinksy, Jintian Liang, Michael McCreedy, Fabian Nagel, Ippokratis Pandis, Panos Parchas, Rahul Pathak, Orestis Poly- chroniou, Foyzur Rahman, Gaurav Saxena, Gokul Sounda...

  5. [5]

    The SafeLoad authors. 2025. The SafeBench Benchmark. https://github.com/ SafeLoad-project/SafeBench. Accessed: 2026-03-02

  6. [6]

    Joyce Cahoon, Wenjing Wang, Yiwen Zhu, Katherine Lin, Sean Liu, Raymond Truong, Neetu Singh, Chengcheng Wan, Alexandra Ciortea, Sreraman Narasim- han, and Subru Krishnan. 2022. Doppler: automated SKU recommendation in migrating SQL workloads to the cloud.Proc. VLDB Endow.15, 12 (Aug. 2022), 3509–3521

  7. [7]

    Xu Chen, Haitian Chen, Zibo Liang, Shuncheng Liu, Jinghong Wang, Kai Zeng, Han Su, and Kai Zheng. 2023. LEON: A New Framework for ML-Aided Query Optimization.Proc. VLDB Endow.16, 9 (May 2023), 2261–2273

  8. [8]

    Alibaba Cloud. 2026. AnalyticDB for MySQL. https://www.alibabacloud.com/ product/analyticdb-for-mysql

Show all 39 references
  1. [9]

    Eli Cortez, Anand Bonde, Benjamin Muzio, Mark Russinovich, Marcus Fontoura, and Ricardo Bianchini. 2017. Resource Central: Understanding and Predicting Workload Resources in the Cloud. InProceedings of the 26th Symposium on Operating Systems Principles (SOSP). 153–167

  2. [10]

    Lee, Ashish Motivala, Abdul Q

    Benoit Dageville, Thierry Cruanes, Marcin Zukowski, Vadim Antonov, Artin Avanes, Jon Bock, Jonathan Claybaugh, Daniel Engovatov, Martin Hentschel, Jiansheng Huang, Allison W. Lee, Ashish Motivala, Abdul Q. Munir, Steven Pelley, Peter Povinec, Greg Rahn, Spyridon Triantafyllis,...

  3. [11]

    Kuno, Umeshwar Dayal, Janet L

    Archana Ganapathi, Harumi A. Kuno, Umeshwar Dayal, Janet L. Wiener, Ar- mando Fox, Michael I. Jordan, and David A. Patterson. 2009. Predicting Multiple Metrics for Queries: Better Decisions Enabled by Machine Learning. InProceed- ings of the 25th International Conference on Da...

  4. [12]

    Nick Glaze, Tria McNeely, Yiwen Zhu, Matthew Gleeson, Helen Serr, Rajeev Bhopi, and Subru Krishnan. 2024. Lorentz: Learned SKU Recommendation Using Profile Data.Proc. ACM Manag. Data2, 3, Article 149 (May 2024), 25 pages

  5. [13]

    Sven Helmer, Peter Wood, and Manuel Stuefer. 2025. Using the Hurwicz Criterion to Optimize Selection Queries Under Partial Ignorance.International Journal of Semantic Computing19 (05 2025), 197–221

  6. [14]

    1951.Optimality Criteria for Decision Making Under Ignorance

    Leonid Hurwicz. 1951.Optimality Criteria for Decision Making Under Ignorance. Discussion Paper: Statistics 370. Cowles Commission for Research in Economics

  7. [15]

    Zhao Lucis Li, Chieh-Jan Mike Liang, Wenjia He, Lianjie Zhu, Wenjun Dai, Jin Jiang, and Guangzhong Sun. 2018. Metis: robustly optimizing tail latencies of cloud systems. InProceedings of the 2018 USENIX Conference on Usenix Annual Technical Conference(Boston, MA, USA)(USENIX A...

  8. [16]

    Zibo Liang, Xu Chen, Yuyang Xia, Runfan Ye, Haitian Chen, Jiandong Xie, and Kai Zheng. 2024. DACE: A database-agnostic cost estimator. In40th IEEE International Conference on Data Engineering, ICDE 2024, Utrecht, The Netherlands, May 13-16,

  9. [17]

    Chenghao Lyu, Qi Fan, Philippe Guyard, and Yanlei Diao. 2024. A Spark Optim- izer for Adaptive, Fine-Grained Parameter Tuning.Proc. VLDB Endow.17, 11 (July 2024), 3565–3579

  10. [18]

    Chenghao Lyu, Guillaume Lachaud, Gabriel Lozano, and Yanlei Diao. 2026. Graph Transformers for Query Plan Representation: Potentials and Challenges.Proc. VLDB Endow.18, 13 (Jan. 2026), 5716–5730

  11. [19]

    Ryan Marcus, Parimarjan Negi, Hongzi Mao, Nesime Tatbul, Mohammad Aliza- deh, and Tim Kraska. 2022. Bao: Making Learned Query Optimization Practical. SIGMOD Rec.51, 1 (June 2022), 6–13

  12. [20]

    Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shiv- akumar, Matt Tolton, Theo Vassilakis, Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, and Jeff Shute. 2020. Dremel: a decade of interactive SQL analysis at web scale.Proc. VLDB Endow.13, 12 (A...

  13. [21]

    Vikram Nathan, Vikramank Singh, Zhengchun Liu, Mohammad Rahman, An- dreas Kipf, Dominik Horn, Davide Pagano, Gaurav Saxena, Balakrishnan Naray- anaswamy, and Tim Kraska. 2024. Intelligent Scaling in Amazon Redshift. In Companion of the 2024 International Conference on Manageme...

  14. [22]

    Olga Poppe, Qun Guo, Willis Lang, Pankaj Arora, Morgan Oslake, Shize Xu, and Ajay Kalhan. 2022. Moneyball: proactive auto-scaling in Microsoft Azure SQL database serverless.Proc. VLDB Endow.15, 6 (Feb. 2022), 1279–1287

  15. [23]

    Calheiros, and Rajkumar Buyya

    Chenhao Qu, Rodrigo N. Calheiros, and Rajkumar Buyya. 2018. Auto-Scaling Web Applications in Clouds: A Taxonomy and Survey.ACM Comput. Surv.51, 4, Article 73 (July 2018), 33 pages. https://doi.org/10.1145/3148149

  16. [24]

    Shaikh Quader, Andres Jaramillo, Sumona Mukhopadhyay, Ghadeer Abuoda, Cal- isto Zuzarte, David Kalmuk, Marin Litoiu, and Manos Papagelis. 2024. Learned- WMP: Workload Memory Prediction Using Distribution of Query Templates. CoRRabs/2401.12103 (2024). arXiv:2401.12103

  17. [25]

    Maximilian Rieger and Thomas Neumann. 2025. T3: Accurate and Fast Perform- ance Prediction for Relational Database Systems With Compiled Decision Trees. Proc. ACM Manag. Data3, 3, Article 227 (June 2025), 27 pages

  18. [26]

    Yaniv Romano, Evan Patterson, and Emmanuel J. Candès. 2019.Conformalized quantile regression. Curran Associates Inc., Red Hook, NY, USA

  19. [27]

    Krzysztof Rzadca, Pawel Findeisen, Jacek Swiderski, Przemyslaw Zych, Przemyslaw Broniek, Jacek Kusmierek, Pawel Gorczyk, Xiao Liu, Gregory Wig- gers, Itai Magid, et al . 2020. Autopilot: workload autoscaling at Google. In Proceedings of the 2020 ACM SIGMOD International Confer...

  20. [28]

    Amazon Web Services. 2026. Amazon Redshift Workload Manage- ment. https://docs.aws.amazon.com/redshift/latest/dg/c_workload_mngmt_ classification.html

  21. [29]

    Chujun Song, Slim Bouguerra, Erik Krogen, and Daniel Abadi. 2025. Evalu- ating Learned Query Performance Prediction Models at LinkedIn: Challenges, Opportunities, and Findings.CoRRabs/2504.17181 (2025)

  22. [30]

    Chunxu Tang, Beinan Wang, Zhenxiao Luo, Huijun Wu, Shajan Dasan, Maosong Fu, Yao Li, Mainak Ghosh, Ruchin Kabra, Nikhil Kantibhai Navadiya, Da Cheng, Fred Dai, Vrushali Channapattan, and Prachi Mishra. 2021. Forecasting SQL Query Cost at Twitter. InIEEE International Conferenc...

  23. [31]

    AnalyticDB Team. 2026. AnalyticDB: Pricing Plans. https://www.alibabacloud. com/help/en/analyticdb/analyticdb-for-mysql/product-overview/billing- overview. Accessed: 2026-05-11

  24. [32]

    Immanuel Trummer, Junxiong Wang, Ziyun Wei, Deepak Maram, Samuel Mose- ley, Saehan Jo, Joseph Antonakakis, and Ankush Rayabhari. 2021. SkinnerDB: Regret-bounded Query Evaluation via Reinforcement Learning.ACM Trans. Database Syst.46, 3, Article 9 (Sept. 2021), 45 pages

  25. [33]

    Yifan Wu, Yuhan Li, Zhenhua Wang, Zhongle Xie, Dingyu Yang, Ke Chen, Lidan Shou, Bo Tang, Liang Lin, Huan Li, and Gang Chen. 2025. SafeLoad: Efficient Admission Control Framework for Identifying Memory-Overloading Queries in Cloud Data Warehouses.Proc. VLDB Endow.19, 4 (Dec. 2...

  26. [34]

    Tim Zeyl, Harshwin Venugopal, Calvin Sun, and Paul Larson. 2024. CASA: Classification-based Adjusted Slot Admission Control for Query Processing Engines. In40th International Conference on Data Engineering, ICDE 2024 - Work- shops, Utrecht, Netherlands, May 13-16, 2024. 278–284

  27. [35]

    Huanchen Zhang, Yihao Liu, and Jiaqi Yan. 2023. Cost-Intelligent Data Analytics in the Cloud. arXiv:2308.09569 [cs.DB] https://arxiv.org/abs/2308.09569

  28. [36]

    Zhuo Zhang, Chao Li, Yangyu Tao, Renyu Yang, Hong Tang, and Jie Xu. 2014. Fuxi: a fault-tolerant resource management and job scheduling system at internet scale.Proc. VLDB Endow.7, 13 (Aug. 2014), 1393–1404. https://doi.org/10.14778/ 2733004.2733012

  29. [37]

    Yue Zhao, Gao Cong, Jiachen Shi, and Chunyan Miao. 2022. QueryFormer: a tree transformer model for query plan representation.Proc. VLDB Endow.15, 8 (April 2022), 1658–1670

  30. [38]

    Yue Zhao, Zhaodonghui Li, and Gao Cong. 2023. A Comparative Study and Com- ponent Analysis of Query Plan Representation Techniques in ML4DB Studies. Proc. VLDB Endow.17, 4 (Dec. 2023), 823–835

  31. [39]

    Rong Zhu, Wei Chen, Bolin Ding, Xingguang Chen, Andreas Pfadler, Ziniu Wu, and Jingren Zhou. 2023. Lero: A Learning-to-Rank Query Optimizer.Proc. VLDB Endow.16, 6 (Feb. 2023), 1466–1479

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.