Pith. sign in

REVIEW 4 major objections 4 minor 10 cited by

A fully autonomous LLM pipeline can synthesize a complete, correct, workload-specific database engine from scratch in minutes to hours, and that engine runs repetitive analytical workloads an order of magnitude faster than a general-purpose

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-02 19:28 UTC pith:4IPQQOQO

load-bearing objection A serious systems paper with a genuinely new pipeline; the speedup claims are plausible but rest on a thinner correctness/validation base than the paper admits. the 4 major comments →

arxiv 2603.02001 v2 pith:4IPQQOQO submitted 2026-03-02 cs.DB

Bespoke OLAP: Synthesizing Workload-Specific One-size-fits-one Database Engines

Johannes Wehrstein , Timo Eckmann , Matthias Jasny , Carsten Binnig This is my paper
classification cs.DB
keywords OLAPworkload specializationLLM code synthesisdatabase engine synthesisquery processinghotpatchingperformance engineeringone-size-fits-one
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper's central claim is that the performance tax of generality in analytical databases can be removed automatically: given a fixed workload—a schema, a set of parameterized query templates, and a dataset—an LLM-driven agent can synthesize a complete in-memory engine specialized to exactly that workload. The paper demonstrates this with two synthesized engines, one for TPC-H and one for CEB, that complete their workloads in 4.6s and 2.3s versus 54.4s and 22.1s for DuckDB—overall speedups of 11.8x and 9.8x, with per-query gains ranging from 1.5x to more than 1400x. A sympathetic reader would care because many real deployments run stable, repetitive query suites, so the ability to support arbitrary ad-hoc SQL is paid on every execution even when never exercised. If the claim holds, per-workload specialization becomes an economically routine operation—about six to twelve hours and roughly $120 in API cost per engine—rather than a multi-year engineering project.

Core claim

The central discovery is that a database engine can be synthesized end-to-end by an agent that alternates code generation with measured feedback, as long as synthesis is structured and the environment is engineered for fast iteration. Concretely, Bespoke OLAP first commits a workload-derived storage plan before any query code is written, then builds a validated correct baseline, then runs four optimization rounds that use actual cardinalities, self-injected tracing, curated expert heuristics, and a final expert-review pass. The engine process stays resident throughout: changes are hot-patched into the running system, validated against a general-purpose engine on scaled-down random parameter

What carries the argument

The load-bearing mechanism is the synthesis loop, not any single algorithm. Its parts are: (1) a staged pipeline that separates storage planning from query implementation and separates correctness from optimization; (2) live hotpatching, which keeps the database process resident so a code change is recompiled in isolation and swapped in, cutting validation turn-around from minutes to seconds; (3) per-query conversation branching, which gives each query its own LLM context while keeping a shared storage layer; and (4) an external regression monitor with snapshot-based rollback that guarantees the artifact improves monotonically. The correctness oracle is the benchmark tool that compares query

Load-bearing premise

The result depends on the assumption that checking correctness on a few scaled-down random instantiations of each query, with results compared against a general-purpose engine, is strong enough to guarantee that the synthesized code is genuinely correct and does not exploit the specific test cases or data used during synthesis.

What would settle it

Take one synthesized engine (say the TPC-H one) and benchmark it on query instantiations drawn from parameter values never seen during synthesis, or on a rescaled dataset with different value correlations; if per-query speedups collapse or correctness fails on those held-out cases, the reported gains are not workload specialization but benchmark-fitting. A simpler version: re-run synthesis on a randomly chosen half of the query template space and test on the other half.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If the claim is correct, the overhead of generality is not a fixed engineering tax: for workloads with high query repetition, a bespoke engine can eliminate schema interpretation, generic operator dispatch, and planning on every execution.
  • The ablation results imply that workload-specific storage design—sort orders, dictionary encodings, denormalized columns—accounts for most of the TPC-H speedup, so future synthesizers should invest heavily in storage planning rather than only query code.
  • Because synthesis completes in hours at roughly $120, resynthesis becomes a routine response to workload drift, even nightly during batch loading, with no downtime if the storage layer is kept.
  • The generated code uses strategies that general-purpose engines rarely employ, including bitmap semi-joins and bitmask prefiltering, suggesting that the space of efficient query implementations is larger than what generic engines explore.
  • The paper's correctness invariant—data remains materializable in flat relational form at all times—means a bespoke engine never reduces capability: ad-hoc queries fall back to a general-purpose path.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Editorial extension: If these results hold under independent reproduction, the field's emphasis should shift from building faster general-purpose engines to building reliable synthesizers, with the correctness oracle—not code generation—as the key research bottleneck.
  • Editorial extension: The paper's own numbers imply an economic break-even test: a workload executed often enough to amortize ~$120 plus hours of synthesis would repay the investment quickly; measuring real fleets' repetition rates would quantify how widely this applies.
  • Editorial extension: Because correctness is checked against a general-purpose engine, the synthesized engine inherits any bug in the reference engine; a natural extension would be to cross-check against a second independent engine or a verified interpreter before trusting exotic optimizations.
  • Editorial extension: The CEB result that speedup grows from 9x to 70x as scale increases suggests the synthesized engine may have lower asymptotic complexity than the baseline; a direct complexity comparison (e.g., counting scans and comparisons) would show whether this is genuine specialization or benchmark-specific tuning.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper presents Bespoke OLAP, an LLM-agent pipeline that synthesizes a dedicated in-memory, single-threaded C++ OLAP engine from a workload contract (schema, query templates, parameter ranges, data files). The pipeline plans a workload-specific storage layout, generates functional query code with correctness checking against DuckDB, then iteratively optimizes through four stages using cardinality hints, self-profiling, curated expert knowledge, and a 'human reference' persona, with hotpatching, regression rollback, and snapshot versioning to keep the loop fast. On TPC-H (SF20) the synthesized engine completes the workload in 4.6 s vs 54.4 s for DuckDB (11.78x), and on CEB (SF2) in 2.3 s vs 22.1 s (9.76x); per-query speedups are reported for every query except CEB Q8a. The paper also reports a scale-factor sweep, an ablation separating storage from query-code effects, a strategy taxonomy, and a detailed synthesis trajectory with tool/cost analysis. The central claim is that fully autonomous synthesis of correct, aggressively specialized engines is practical.

Significance. If correct, this is a substantial systems contribution: it would make workload-specific 'one-size-fits-one' engines economically feasible and provide evidence that a large fraction of OLAP overhead is due to generality. The infrastructure contributions—per-query conversation branching, live hotpatching, external regression monitoring, snapshot-based rollback—are useful independent of the headline speedups, and the release of code/artifacts plus detailed development-trajectory data strengthens reproducibility. The paper is also honest about scope (in-memory, single-threaded, fixed workload). The principal weakness is empirical validation: the correctness oracle is finite random testing with no reported coverage, the scaling experiment is underspecified, one CEB query is excluded, and no repeated-run variance is reported. These issues bear directly on the claim that the speedups reflect genuine specialization rather than benchmark-specific artifacts.

major comments (4)
  1. [§4, 'Correctness needs Continuous & Fast Testing'] The entire validity of the synthesis loop rests on the claim that testing on 'several scaled-down versions' and 'a diverse set of parameter instantiations' prevents hardcoding. However, no sample sizes, number of instantiations, seed policy, or coverage metrics are reported, and the test is explicitly a finite random test. More importantly, the anti-hardcoding validation is described as part of the implementation phase on scaled-down data; the optimization phase switches to the full dataset and is not described as re-running that validation on full-scale instantiations. An engine that passes a finite sample can still contain data-dependent constants (row-count thresholds, array sizes, precomputed aggregates) that are silently wrong for other allowed instantiations or for the larger scale factors used in Figure 6. Because one incorrect result invalidates the runtime comparison, this gap i
  2. [§5.2.2, Figure 6] Figure 6 reports speedups up to SF100 (TPC-H) and SF10 (CEB) without stating whether the engines at each scale were resynthesized/revalidated or whether the same binary was loaded with larger data. If the latter, correctness at these scales is not established, because the optimization phase used only one full-scale dataset; if the former, the comparison is against different artifacts and synthesis cost should be reported. Please state per-scale synthesis/validation protocol.
  3. [Footnote 1 / §5.2.1] Footnote 1 excludes CEB Q8a from all plots due to 'vastly spiking' DuckDB runtimes, but the text claims Bespoke outperforms DuckDB on 'every single query' (§5.2.1) and the total CEB speedup is computed without Q8a. Excluding a query with unstable baseline can bias both total and per-query claims. The standard remedy is to run DuckDB multiple times and report medians/percentiles rather than dropping the query; please provide the complete Q8a results and a sensitivity analysis of the total speedup with Q8a included.
  4. [§5.2, Figures 1, 5, 6] All runtimes appear to be single measurements; no error bars, repeated runs, or variance statistics are reported. Given per-query speedups as high as 1466x (CEB) and the stated instability of DuckDB on some CEB instantiations, single-run measurements are not sufficient to support the precise speedup factors. Please report at least median and min/max over several runs for the headline figures, and for DuckDB's unstable queries use a robust statistic instead of exclusion.
minor comments (4)
  1. [§5.3.1/§5.3.2 vs Table 1/Figure 7] The CEB final speedup is inconsistent: §5.3.1 and §5.3.2 state 8.7×/8.69×, while Figure 7 and Table 1 give 9.74×; Figure 1 caption and §5.2.1 give 9.76×. Please unify.
  2. [§5.1 vs Conclusion] DuckDB version is given as 1.1.4 in §5.1 but v1.4.4 in the Conclusion. Please use one version.
  3. [§3.1, expert-knowledge link] The statement 'The complete expert-knowledge file can be found here' does not include a visible URL in the text; please provide the link in the references or artifact appendix.
  4. [Figure 8] The timeline's query identifiers and correctness markers are very small and hard to read in print; consider a vector version or a tabular summary of correctness episodes.

Circularity Check

0 steps flagged

No significant circularity: the speedup claims are measured on external benchmarks, and DuckDB is used as an oracle/hint source rather than as an input that forces the result.

full rationale

The paper's central claim is an empirical synthesis result, not a derivation from assumed equations. The synthesis loop uses DuckDB as a correctness oracle and as a source of cardinality hints ('reports correctness by comparing results against DuckDB' and 'the agent receives signals from executing one randomly sampled query plan per query template from DuckDB, annotated with automatically retrieved actual cardinalities'), but this does not make the reported 11.78x/9.76x speedups circular: the agent must still generate and validate C++ code, the benchmark tool measures actual runtimes, and the final engines could have failed to improve. Optimizing directly on the target workload is the intended mode of specialization ('our approach can thus directly measure alternatives during synthesis and hard-code the fastest one into the final artifact'), not a hidden fit of the evaluation metric. The only self-citation with load-bearing potential is [32] for the dataset scaler used in downscaled validation; that tool supplies test data, and its correctness is external to the present claims. It is not invoked as a uniqueness theorem or an ansatz, and it does not define the performance result. The scaled-down correctness testing is a finite random test and cannot rule out hardcoding by logical necessity, but that is an experimental-coverage limitation, not circular reasoning: no quoted step reduces an output to an input by construction. Accordingly no circular steps are listed.

Axiom & Free-Parameter Ledger

0 free parameters · 5 axioms · 0 invented entities

No numerical parameters are fitted to data. The pipeline involves many hand-chosen design choices (number of optimization stages, prompts, expert-knowledge file, use of GPT 5.2 Codex, scale factors), but these are not free parameters in the quantitative sense. No new physical or theoretical entities are introduced; the 'Bespoke Agent' is a software system, not a postulated entity with independently falsifiable evidence.

axioms (5)
  • domain assumption DuckDB returns correct results for all query instantiations.
    Used as the sole correctness oracle in §3.1 and §4; all validation compares Bespoke engines against DuckDB.
  • domain assumption Scaled-down datasets preserve the correctness-relevant and performance-relevant characteristics of the full dataset.
    Section 4 validates on scaled-down versions using the GRACEFUL scaler [32]; correctness/performance is assumed to transfer to full SF.
  • domain assumption The LLM generates code that generalizes across the parameter space rather than memorizing specific query instantiations.
    The paper's anti-hardcoding mitigation (§4, 'preventing hardcoding to exact rowIds or counts') is an assumption about LLM behavior; the evaluation does not prove generalization beyond the tested instantiations.
  • domain assumption The performance measurements are stable and representative despite no repeated-run variance reporting.
    Section 5.1 describes a single EPYC machine and CPU pinning, but no confidence intervals are given, so the reported speedups assume noise is small.
  • domain assumption Compiler and OS behavior are standard and do not introduce artifacts.
    Required for C++ code generation and timing; not explicitly tested.

pith-pipeline@v1.3.0-alltime-deepseek · 19814 in / 15991 out tokens · 143378 ms · 2026-08-02T19:28:39.078835+00:00 · methodology

0 comments
read the original abstract

Modern OLAP engines are designed to support arbitrary analytical workloads, but this generality incurs structural overhead, including runtime schema interpretation, indirection layers, and abstraction boundaries, even in highly optimized systems. An engine specialized to a fixed workload can eliminate these costs and exploit workload-specific data structures and execution algorithms for substantially higher performance. Historically, constructing such bespoke engines has been economically impractical due to the high manual engineering effort. Recent advances in LLM-based code synthesis challenge this tradeoff by enabling automated system generation. However, naively prompting an LLM to produce a database engine does not yield a correct or efficient design, as effective synthesis requires systematic performance feedback, structured refinement, and careful management of deep architectural interdependencies. We present Bespoke OLAP, a fully autonomous synthesis pipeline for constructing high-performance database engines tightly tailored to a given workload. Our approach integrates iterative performance evaluation and automated validation to guide synthesis from storage to query execution. We demonstrate that Bespoke OLAP can generate a workload-specific engine from scratch within minutes to hours, achieving order-of-magnitude speedups over modern general-purpose systems such as DuckDB.

Figures

Figures reproduced from arXiv: 2603.02001 by Carsten Binnig, Johannes Wehrstein, Matthias Jasny, Timo Eckmann.

Figure 1
Figure 1. Figure 1: Synthesized Bespoke engines exceed the perfor [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the Bespoke OLAP idea: one engine is generated per workload (left), and the pipeline to synthesize [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Steps to produce a Bespoke Engine. Each step is ex [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Overview of the infrastructure supporting LLM [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Per-query runtimes for TPC-H (SF=20) and CEB (SF=2). Bespoke-TPCH/CEB outperforms DuckDB on every query. [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Speedups over DuckDB at different scale factors for [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Cumulative impact of each optimization stage on [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Development timeline of Bespoke-TPCH. The upper plot shows context size (left axis) and cumulative lines of code [PITH_FULL_IMAGE:figures/full_fig_p011_8.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 10 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Breaking Database Lock-in: Agentic Regeneration of High Performance Storage Readers for Database Bypass

    cs.DB 2026-07 conditional novelty 7.0

    LLM-assisted synthesis of database storage readers that bypass engines and materialize PostgreSQL/MySQL data as Apache Arrow for analytical engines.

  2. From Custom-Fit to Portable: Bridging the Gap Between Synthesized and Engineered GPU Query Execution

    cs.DB 2026-07 conditional novelty 7.0

    LLM-synthesized GPU query kernels outperform engineered engines by 7.4x, but a portable SYCL engine with lifted optimizations closes the gap to 1.27x, suggesting engineering remains preferable on GPUs.

  3. Bespoke-Card: Why Tune When You Can Generate? Synthesizing Workload-Specific Cardinality Estimators

    cs.DB 2026-06 unverdicted novelty 7.0

    Bespoke-Card synthesizes workload-specific cardinality estimators as executable code via agent planning, coding, and validation, cutting PostgreSQL runtime on JOB by 33% and median q-error by 41%.

  4. Bespoke-Card: Why Tune When You Can Generate? Synthesizing Workload-Specific Cardinality Estimators

    cs.DB 2026-06 conditional novelty 7.0

    Agent-driven code synthesis produces workload-specialized cardinality estimators that cut PostgreSQL runtime 33% on JOB and 68% on JOB-Complex while lowering median q-error from 190.5 to 11.5.

  5. The Time is Here for Just-in-Time Systems: Challenges and Opportunities

    cs.DB 2026-05 unverdicted novelty 7.0

    Jitskit is an iterative LLM-based synthesis pipeline that generates key-value stores matching spec cards for YCSB workloads, resources, and properties, outperforming SOTA baselines on all 18 tested cases by up to 4.6x.

  6. Tailwind: A Practical Framework for Query Accelerators

    cs.DB 2026-04 unverdicted novelty 7.0

    Tailwind introduces ALPs and ML-based planning to integrate workload-specific query accelerators into standard RDBMSes, achieving 1.38x average (up to 29x) speedup on TPC-H queries.

  7. FM-Agent: Scaling Formal Methods to Large Systems via LLM-Based Hoare-Style Reasoning

    cs.SE 2026-04 unverdicted novelty 7.0

    FM-Agent is the first framework to automate compositional Hoare reasoning for large systems by having LLMs derive natural-language function specs from caller intent and then generate tests that found 522 new bugs in s...

  8. SpecDB: LLM-Generated Customized Databases via Feature-Oriented Decomposition

    cs.DB 2026-05 unverdicted novelty 6.0

    SpecDB generates a 23,779-line Rust database via LLM subagents that matches PostgreSQL and MySQL tpmC on TPC-C while using roughly 3% of their code size.

  9. FM-Agent: Scaling Formal Methods to Large Systems via LLM-Based Hoare-Style Reasoning

    cs.SE 2026-04 unverdicted novelty 6.0

    FM-Agent automates top-down natural-language Hoare reasoning with LLMs and reports 522 new bugs in large, previously tested systems up to 143k LoC.

  10. Rethinking Query Optimization for Multi-Agent Systems [Vision]

    cs.DB 2025-12 conditional novelty 6.0

    Agentic data pipelines are built by hand today; this paper sets a research agenda for automatically optimizing their structure, model choices, and execution engines jointly as a new query-optimization problem.

Reference graph

Works this paper leans on

34 extracted references · 3 linked inside Pith · cited by 8 Pith papers

  1. [1]

    Sanjay Agrawal, Surajit Chaudhuri, Lubor Kollar, Arun Marathe, Vivek Narasayya, and Manoj Syamala. 2005. Database tuning advisor for microsoft sql server 2005. InProceedings of the 2005 ACM SIGMOD international conference on Management of data. 930–932

    2005

  2. [2]

    Sanjay Agrawal, Surajit Chaudhuri, and Vivek R Narasayya. 2000. Automated selection of materialized views and indexes in SQL databases. InVLDB, Vol. 2000. 496–505

    2000

  3. [3]

    Sanjay Agrawal, Vivek Narasayya, and Beverly Yang. 2004. Integrating vertical and horizontal partitioning into automated physical database design. InProceed- ings of the 2004 ACM SIGMOD international conference on Management of data. 359–370

    2004

  4. [4]

    Yanif Ahmad, Oliver Kennedy, Christoph Koch, and Milos Nikolic. 2012. DBToaster: higher-order delta processing for dynamic, frequently fresh views. Proceedings of the VLDB Endowment5, 10 (2012), 968–979

    2012

  5. [5]

    Boncz, Marcin Zukowski, and Niels Nes

    Peter A. Boncz, Marcin Zukowski, and Niels Nes. 2005. MonetDB/X100: Hyper- Pipelining Query Execution. InProceedings of the 2nd Biennial Conference on Innovative Data Systems Research (CIDR). 225–237

    2005

  6. [6]

    Hassan Chafi. 2014. Building efficient query engines in a high-level language. Proceedings of the VLDB Endowment7, 10 (2014), 853–864

    2014

  7. [7]

    Surajit Chaudhuri and Vivek Narasayya. 1998. AutoAdmin “what-if” index analysis utility.ACM SIGMOD Record27, 2 (1998), 367–378

    1998

  8. [8]

    Surajit Chaudhuri and Vivek R Narasayya. 1997. An efficient, cost-driven index selection tool for Microsoft SQL server. InVLDB, Vol. 97. San Francisco, 146–155

    1997

  9. [9]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374(2021)

    Pith/arXiv arXiv 2021

  10. [10]

    Matteo Frigo and Steven G Johnson. 1998. FFTW: An adaptive software archi- tecture for the FFT. InProceedings of the 1998 IEEE International Conference on Acoustics, Speech and Signal Processing, ICASSP’98 (Cat. No. 98CH36181), Vol. 3. Ieee, 1381–1384

    1998

  11. [11]

    2024.Rediscovering Transaction Processing from History and First Principles

    Joran Dirk Greef. 2024.Rediscovering Transaction Processing from History and First Principles. TigerBeetle. https://tigerbeetle.com/blog/2024-07-23-rediscovering- transaction-processing-from-history-and-first-principles/

    2024

  12. [12]

    Benjamin Hilprecht, Carsten Binnig, Tiemo Bang, Muhammad El-Hindi, Ben- jamin Hättasch, Aditya Khanna, Robin Rehrmann, Uwe Röhm, Andreas Schmidt, Lasse Thostrup, and Tobias Ziegler. 2020. DBMS Fitting: Why should we learn what we already know?. InCIDR. www.cidrdb.org

    2020

  13. [13]

    Alfons Kemper and Thomas Neumann. 2011. HyPer: A hybrid OLTP&OLAP main memory database system based on virtual memory snapshots. In2011 IEEE 27th International Conference on Data Engineering. IEEE, 195–206

    2011

  14. [14]

    Andreas Kipf, Thomas Kipf, Bernhard Radke, Viktor Leis, Peter Boncz, and Alfons Kemper. 2018. Learned cardinalities: Estimating correlated joins with deep learning.arXiv preprint arXiv:1809.00677(2018)

    Pith/arXiv arXiv 2018

  15. [15]

    Tim Kraska, Alex Beutel, Ed H Chi, Jeffrey Dean, and Neoklis Polyzotis. 2018. The case for learned index structures. InProceedings of the 2018 international conference on management of data. 489–504

    2018

  16. [16]

    Viktor Leis, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2014. Morsel- driven parallelism: a NUMA-aware query evaluation framework for the many- core age. InProceedings of the 2014 ACM SIGMOD international conference on Management of data. 743–754

    2014

  17. [17]

    Viktor Leis, Andrey Gubichev, Atanas Mirchev, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2015. How good are query optimizers, really?Proceedings of the VLDB Endowment9, 3 (2015), 204–215

    2015

  18. [18]

    Ryan Marcus. 2023. Learned Query Superoptimization. InProceedings of the AIDB 2023 Workshp

    2023

  19. [19]

    Ryan Marcus, Parimarjan Negi, Hongzi Mao, Chi Zhang, Mohammad Alizadeh, Tim Kraska, Olga Papaemmanouil, and Nesime Tatbul. 2019. Neo: A learned query optimizer.arXiv preprint arXiv:1904.03711(2019)

    Pith/arXiv arXiv 2019

  20. [20]

    Parimarjan Negi, Ryan Marcus, Andreas Kipf, Hongzi Mao, Nesime Tatbul, Tim Kraska, and Mohammad Alizadeh. 2021. Flow-loss: learning cardinality estimates that matter.Proceedings of the VLDB Endowment14, 11 (2021), 2019–2032

    2021

  21. [21]

    Thomas Neumann. 2011. Efficiently Compiling Efficient Query Plans for Modern Hardware.Proceedings of the VLDB Endowment4, 9 (2011), 539–550. https: //doi.org/10.14778/2002938.2002940

    arXiv 2011

  22. [22]

    Thomas Neumann and Michael J. Freitag. 2020. Umbra: A Disk-Based System with In-Memory Performance. In10th Conference on Innovative Data Systems Research, CIDR 2020, Amsterdam, The Netherlands, January 12-15, 2020, Online Proceedings. www.cidrdb.org. https://vldb.org/cidrdb/2020/umbra-a-disk-based- system-with-in-memory-performance.html

    2020

  23. [23]

    2025.OpenAI Codex

    OpenAI. 2025.OpenAI Codex. OpenAI. https://openai.com Code generation model

    2025

  24. [24]

    Andrew Pavlo, Gustavo Angulo, Joy Arulraj, Haibin Lin, Jiexi Lin, Lin Ma, Prashanth Menon, Todd C Mowry, Matthew Perron, Ian Quah, et al. 2017. Self- Driving Database Management Systems.. InCIDR, Vol. 4. 1

    2017

  25. [25]

    Mark Raasveldt and Hannes Mühleisen. 2019. Duckdb: an embeddable analytical database. InProceedings of the 2019 international conference on management of data. 1981–1984

    2019

  26. [26]

    One Size Fits All

    Michael Stonebraker and Ugur Çetintemel. 2005. “One Size Fits All”: An Idea Whose Time Has Come and Gone. InProceedings of the 21st International Confer- ence on Data Engineering (ICDE). IEEE, 2–11. https://doi.org/10.1109/ICDE.2005.1

    doi:10.1109/icde.2005.1 2005

  27. [27]

    Transaction Processing Performance Council. 2014. TPC Benchmark H (Deci- sion Support) Standard Specification. https://www.tpc.org/TPC_Documents_ Current_Versions/pdf/TPC-H_v3.0.1.pdf. Version 3.0.1

    2014

  28. [28]

    Immanuel Trummer. 2022. CodexDB: Synthesizing code for query processing from natural language instructions using GPT-3 Codex.Proceedings of the VLDB Endowment15, 11 (2022), 2921–2928

    2022

  29. [29]

    Immanuel Trummer. 2023. Demonstrating gpt-db: Generating query-specific and customizable code for sql processing with gpt-4.Proceedings of the VLDB Endowment16, 12 (2023), 4098–4101

    2023

  30. [30]

    Dana Van Aken, Andrew Pavlo, Geoffrey J Gordon, and Bohan Zhang. 2017. Automatic database management system tuning through large-scale machine learning. InProceedings of the 2017 ACM international conference on management of data. 1009–1024

    2017

  31. [31]

    Alexander Van Renen, Dominik Horn, Pascal Pfeil, Kapil Eknath Vaidya, Wenjian Dong, Murali Narayanaswamy, Zhengchun Liu, Gaurav Saxena, Andreas Kipf, and Tim Kraska. 2024. Why TPC is not enough: An analysis of the Amazon Redshift fleet. (2024)

    2024

  32. [32]

    Johannes Wehrstein, Tiemo Bang, Roman Heinrich, and Carsten Binnig. 2025. GRACEFUL: A Learned Cost Estimator for UDFs. In41st IEEE International Conference on Data Engineering, ICDE 2025, Hong Kong, May 19-23, 2025. IEEE, 2450–2463. https://doi.org/10.1109/ICDE65448.2025.00185

    arXiv 2025

  33. [33]

    R Clint Whaley, Antoine Petitet, and Jack J Dongarra. 2001. Automated empirical optimizations of software and the ATLAS project.Parallel computing27, 1-2 (2001), 3–35

    2001

  34. [34]

    Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. [n.d.]. React: Synergizing reasoning and acting in language models. InThe eleventh international conference on learning representations. 13