Pith. sign in

REVIEW 4 major objections 4 minor 39 references

Hollywood: Towards a Large Movie Dataset for Database Benchmarking

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

Pith's one-line read A synthetic movie dataset reproduces IMDb's hardest cardinality-estimation errors, giving researchers a fresh, scaleable benchmark.

desk verdict Useful generator for IMDb-style benchmarking; the headline difficulty claim needs qualifying due to workload selection and single-seed results. read the letter →

arxiv 2607.19666 v1 pith:CE5QN57N submitted 2026-07-22 cs.DB

classification cs.DB
keywords cardinalityestimationsyntheticdatagenerationIMDb/JOBbenchmarktemporalsignedgraphLLM-generatedpriorsqueryoptimizerbenchmarkingscalefactorgeneralizationtesting
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

Hollywood is a generator for synthetic movie databases meant to behave like the IMDb snapshot behind the JOB benchmarks. The paper's central claim is that a 200,000-movie instance, Hollywood-200K, induces cardinality estimation errors comparable to or exceeding those observed on the original IMDb dataset, across both traditional and learned estimators. If this holds, researchers can generate fresh, reproducible benchmark instances instead of reusing one fixed dump, and can ask whether estimators generalize beyond the single IMDb distribution. The release includes generation settings, adapted SQL workloads, and labels needed to replay the experiments.

What carries the argument

The central mechanism is a temporal signed graph with typed, signed, weighted edges (collaboration, rivalry, company affinity, and similar relations) that are active in specific year intervals. During movie assembly, every choice—a person, company, or keyword—is drawn with probability proportional to a product of factors including current popularity, movie-fit, capacity, latent similarity, graph affinity, and policy constraints. Because the same graph state conditions cast, company, keyword, and metadata choices, cross-table correlations are generated jointly. LLM-generated priors are consumed only as parsed, versioned semantic assets, and the seeded code determines materialization, so the p

What would settle it

Run the generator several times with different seeds, rebind the original JOB templates to whatever literals appear without dropping queries for being easy, and compute the same p95 Q-errors. If Hollywood's tails consistently fall below the matched IMDb sample, or if difficulty varies wildly across seeds, the claim that Hollywood reproduces or exceeds IMDb difficulty would not hold.

Watch

Extended reading notes

Core claim

On the released Hollywood-200K instance (200,000 primary movies, roughly 19.7 million rows), the authors adapted the JOB-Light, JOB, and JOB-Complex workloads to literals that exist in the generated database and measured PostgreSQL, DuckDB, MSCN, and ZeroShot. Their central result is that full-query cardinality-estimation errors on Hollywood are comparable to or larger than on the original IMDb: PostgreSQL p95 Q-error reaches 2.37×10^4 on JOB and 3.07×10^5 on JOB-Complex, DuckDB's JOB-Complex median is 190, and MSCN's tail errors exceed the IMDb references even though medians stay low. Because single-table selection errors are much smaller, the difficulty appears after joins, matching what m

Load-bearing premise

The load-bearing premise is that the single generated instance and its 213 adapted queries are a fair sample of what the generator produces, rather than a set chosen because it was hard: if the adaptation procedure systematically kept the most stressful queries, the headline comparison would reflect query selection rather than the data distribution.

Editorial extensions

If this is right

  • Hollywood-200K can serve as a fresh, structurally similar but previously unseen dataset for testing whether cardinality estimators generalize beyond the original IMDb snapshot.
  • The generator exposes primary-movie count, years, entity-pool sizes, and seed as parameters, so benchmark difficulty can be studied as data size grows.
  • The release of generation settings, LLM-output provenance, adapted SQL, and labels lets other groups reproduce or extend the measurements without the original IMDb dump.
  • The finding that errors concentrate after joins rather than in base selections suggests Hollywood captures the join-correlation patterns that make JOB hard.
  • If the 'comparable or exceeding' result holds across seeds and scale factors, Hollywood gives the JOB research line a controllable analogue to the synthetic TPC family.

Reading between the lines

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

  • Because every instance is seeded, a natural next step is to generate multiple Hollywood instances from the same profile and measure whether estimator rankings or error tails are stable across seeds; this would turn the current single-instance claim into a property of the generator.
  • The workload adaptation explicitly keeps only queries that parse, execute, have positive labels, and stress both systems; that selection may account for part of the reported difficulty. Rebinding the original JOB templates to Hollywood literals without filtering would isolate the data's contribution.
  • A direct test of the LLM priors' contribution would be to run the generator with purely random dictionaries and check whether the join-error tails survive; if they do, the temporal graph alone carries the difficulty.
  • If seed variation and workload selection are controlled, Hollywood-like generators could support cross-instance distribution-shift studies, letting researchers compare estimators under controlled correlation changes rather than fixed snapshots.
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 / 4 minor

Summary. The paper introduces Hollywood, a synthetic IMDb-compatible benchmark generator that combines LLM-generated semantic priors with a deterministic temporal signed graph and chronological assembly to produce a 200,000-primary-movie export (19.7M rows, 351,455 title rows). It adapts JOB-Light, JOB, and JOB-Complex workloads and evaluates PostgreSQL, DuckDB, MSCN, and ZeroShot on full-query cardinality, single-table selection, and selected-plan runtime prediction, comparing against both full IMDb and a title-count-matched IMDb sample. The central claim is that Hollywood-200K induces cardinality estimation errors comparable to or exceeding those on IMDb. The release includes generation settings, prompt/LLM-output provenance, adapted SQL, labels, and evaluation artifacts.

Significance. If the central claim is supported, Hollywood addresses a real limitation of the JOB/IMDb ecosystem: the absence of a scalable, reproducible IMDb-compatible generator that preserves correlated predicates and multi-join stress. The paper's strengths are the deterministic and auditable generation pipeline, the explicit release of provenance and adapted workloads, and the use of multiple estimator families (PostgreSQL, DuckDB, MSCN, ZeroShot). These properties make the artifact useful for generalization testing regardless of the headline difficulty claim. However, the headline difficulty claim is presently not established with sufficient rigor: the workload adaptation filter, the use of a single generated instance, and the metric-dependent nature of the evidence are load-bearing concerns.

major comments (4)
  1. [§2 'Rows, SQL, and Labels'; §3.1 Setup] The headline comparison in Fig. 2 rests on a 213-query Hollywood workload produced by an adaptation procedure that 'retains candidates that parse, execute, and have positive labels, favoring those that stress both PostgreSQL and DuckDB.' The canonical JOB workloads on full IMDb are not filtered this way. If the stress-favoring selection preferentially keeps hard queries, the p95 differences (PG JOB 2.37e4 vs 1.15e4; JOB-Complex 3.07e5 vs 6.64e4) may partly measure the filter. The paper reports no candidate-pool size, no discard counts, and no Q-errors for discarded candidates. Please add an unfiltered or neutral adapted workload, or report statistics for all candidates before the stress-favoring filter, and show the conclusion is insensitive to this selection.
  2. [§3.2 and Fig. 2] The abstract and §3.2 state that Hollywood 'induces cardinality estimation errors comparable to or exceeding' IMDb, but the evidence in Fig. 2 is metric-dependent and mixed. PostgreSQL medians are much lower on Hollywood (28 vs 261 on JOB; 20.5 vs 758 on JOB-Complex) while p95s are higher; DuckDB's median is higher only on JOB-Complex (190 vs 117 and 11.7), and MSCN medians are similar (e.g., 4.23 vs 4.10 on JOB). The disjunction 'comparable or exceeding' can hold on selected statistics and reverse on others. Please specify the target property (e.g., tail p95, whole distribution, or a pre-registered criterion) before reporting, and provide a statistical comparison rather than selecting favorable aggregates.
  3. [§2 (run specification, seed); §3.1 Setup] All results are from one generated Hollywood-200K instance, and the seed is never reported. A single draw cannot establish a generator-level difficulty claim; it can only characterize this one export. If the claim is about the artifact rather than the generator, the wording should be narrowed accordingly. Please report the seed and ideally repeat generation, workload adaptation, and the main Q-error measurements on several seeds (e.g., 3–5) to show the headline differences are stable.
  4. [§3.4 Selected-Plan Runtime Prediction] PostgreSQL cost is mapped to milliseconds with a 'workload-specific geometric-mean scale.' If this scale is fitted separately for Hollywood and matched IMDb, it can absorb systematic calibration differences and make PG-cost error comparisons hard to interpret. Please state explicitly whether the scale is computed per workload/dataset, and report whether the conclusions hold under a common calibration or with actual execution times.
minor comments (4)
  1. [§3.1, footnote 1] The footnote says 28 of the 30 literal-adapted JOB-Complex queries on the matched IMDb sample have nonzero cardinality and all full-query summaries use this fixed subset. It is unclear whether the Hollywood workload's 30 JOB-Complex queries are compared against 28 matched-sample queries. Please state the exact query counts used in each plotted distribution.
  2. [§1 Introduction] Typo in 'it has beenthedataset for learned-cardinality...' — missing spaces and article.
  3. [§3.1 Setup] The phrase 'repeated seeds' for MSCN is not quantified; no seed values or variance across MSCN runs are reported. Please provide the seed range or state that variance was negligible.
  4. [§3.2 and Fig. 2] The signed Q-error boxes are described as 'mostly below zero' for PostgreSQL, but the definition of signed Q-error (positive = overestimation, negative = underestimation) should be stated in the caption or text, since the orientation is needed to interpret the claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Q-error results are empirical measurements; workload stress-filtering is a confound, not a constructional equivalence.

full rationale

The paper's central claim is an empirical benchmark result, not a derived quantity: Hollywood-200K is generated, JOB-family templates are adapted to its literals, and PostgreSQL/DuckDB/MSCN are executed to measure Q-errors, whose p95 values are then compared with IMDb references. No parameter is fitted to match the IMDb error distributions, and the headline numbers are measurements rather than identities. The only potentially self-referential element is §2's workload adaptation ('favoring those that stress both PostgreSQL and DuckDB'). This is a selection-bias/confound concern, but it is not a circularity under the required standard: stress is not defined as the reported Q-error, the database remains fixed during the search, and no equation or construction makes the measured p95 values equal to the selection criterion. The matched sample is explicitly described as 'a title/cast-scale reference, not a distributional twin,' acknowledging a limitation. Self-citations (Redbench, MSCN) are used for related work and estimator setup, not as load-bearing uniqueness or ansatz imports. The PG-cost-to-ms geometric-mean scale is a transparent calibration for the runtime-prediction section and does not affect the cardinality-error claim. Hence no circular step can be exhibited.

Assumptions & free parameters 3 free parameters · 4 assumptions · 2 invented entities

The generator rests on a stack of unverified distributional assumptions: LLM priors stand in for IMDb's semantic coupling, temporal-graph dynamics are assumed to produce join-relevant correlations, and the canonical IMDb schema/JOB templates are assumed to transfer. The paper is honest about the LLM-bias risk (§2.1) but provides no fidelity comparison against IMDb's actual distributions. The selection-weight factor values are unreported free parameters, and the PG-cost-to-ms scale is fitted per workload. No physics-style invented entity (particle/force/dimension) appears; the LLM latent variables and signed-edge graph are released constructs with external handles.

free parameters (3)
  • Selection-weight factors w_pop, w_fit, w_cap, w_latent, w_graph, w_policy = Not reported
    §2.3 defines Pr(x|z_m, G_y, y) as proportional to the product of these factors but does not report their values or how they were set. They shape the joint distribution of the entire generated database; the central claim (that Hollywood produces JOB-like errors) depends on them without independent evidence.
  • Workload-specific PG cost-to-ms geometric-mean scale = Per workload (JOB-Light / JOB / JOB-Complex), values not given
    §3.1 'Runtime Prediction': 'We map PostgreSQL cost to milliseconds with a workload-specific geometric-mean scale.' This fitted calibration directly shapes the runtime-prediction errors in Fig. 3.
  • Generation profile (primary-movie count, years, entity-pool sizes, seed) = 200,000 primary movies; years approximately 2022-2050 (Fig. 1); seed value not stated
    The evaluation is measured on a single profile and a single seed; without the seed value or multiple seeds, 'comparable or exceeding' cannot be separated from a single draw of the generator.
assumptions (4)
  • domain assumption LLM-generated priors are a valid proxy for the semantic coupling structure of IMDb attributes.
    §2.1: 'we use the model as a nonuniform world-building prior'; the paper itself notes training-data biases can enter the priors (refs [2,4]). The benchmark premise is that these priors produce JOB-like predicate correlations, but no distributional fidelity check against IMDb is provided.
  • domain assumption The temporal signed graph's edge/evolution semantics generate join-relevant correlations similar to IMDb's.
    §2.2-2.3 describe graph state, type-2 SCD edge versioning, and chronological assembly. The claim that Hollywood stresses estimators 'comparable to' IMDb requires these dynamics to produce realistic multi-relation correlations, which is asserted rather than validated against IMDb.
  • domain assumption The canonical PostgreSQL IMDb schema and JOB-family templates transfer to the synthetic instance.
    §3.1 uses 'the canonical PostgreSQL IMDb schema' for labels and adapted JOB/JOB-Light/JOB-Complex templates. If the schema semantics (e.g., movie_info_idx rating outliers) do not transfer, the adapted workload measures something different from the original JMDB difficulty.
  • domain assumption Gemini 3.1 Flash-Lite Preview outputs are parseable, normalized, versioned, and fully captured in the released provenance.
    §2.1 states prompts are parsed as JSON, normalized, deduplicated, and versioned. Reproducibility of the shipped instance depends on this pipeline and on the released priors being exactly the ones used to generate Hollywood-200K.
invented entities (2)
  • LLM world-building latent variables (movie profile z_m, signed-edge type/strength/provenance, latent deltas) independent evidence
    purpose: To couple names, genres, career stages, company strategies, and risk profiles so that generated rows carry correlated predicates like IMDb rows do.
    These latents are constructs, but they are released as versioned artifacts consumed by seeded code, and validation/repair reports are shipped, giving an external falsifiable handle: the same profile plus seed should regenerate the same database.
  • Temporal signed graph with type-2 SCD edge versions independent evidence
    purpose: To carry cross-entity dependencies (friendship, rivalry, avoid-lists, company-affinity) across synthetic years and condition movie assembly.
    Edges carry provenance records and active-year intervals, and the release includes validation/repair reports, so the construct is inspectable and regenerable rather than a purely internal postulate with no external handle.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Hollywood: Towards a Large Movie Dataset for Database Benchmarking." pith.science (2026). https://pith.science/paper/CE5QN57N

@misc{pith2026260719666,
  author       = {Pith},
  title        = {Pith review of: Hollywood: Towards a Large Movie Dataset for Database Benchmarking},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CE5QN57N}},
  note         = {Machine review of arXiv:2607.19666}
}
read the original abstract

The IMDb real-world dataset of the JOB benchmark has been extensively used in the last decade as part of the research line on cardinality estimation, given its ability to stress test both traditional and learned estimators. However, unlike the synthetic TPC family, it does not come with a scale factor, being a simple dump. We introduce Hollywood, a synthetic IMDb-compatible benchmark generator that combines LLM-generated semantic dictionaries with deterministic temporal-graph-based relational data generation. We analyze a preliminary Hollywood-200K, which contains 200,000 primary movies, generated series and episode title rows, 19.7M IMDb-style rows, and 213 nonzero JOB-Light, JOB, and JOB-Complex queries. Experiments with two open systems demonstrate that Hollywood induces cardinality estimation errors comparable to or exceeding those observed on the original IMDb dataset. The release includes generation settings and prompt/LLM-output provenance together with adapted SQL and labels, enabling tests of whether cardinality estimators generalize beyond a fixed movie snapshot and distribution.

Figures

Figures reproduced from arXiv: 2607.19666 by the authors.

Figure 1
Figure 1. Hollywood generation flow from LLM-authored priors to temporal graph state, movie assembly, validation/repair, and the released [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Signed full-query cardinality error. Boxes compare full IMDb, the matched IMDb sample, and Hollywood; MSCN uses separately [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Signed selected-plan runtime-prediction error comparing [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 9 canonical work pages

  1. [1]

    Arvind Arasu, Raghav Kaushik, and Jian Li. 2011. Data Generation Using Declara- tive Constraints. InProceedings of the 2011 ACM SIGMOD International Conference on Management of Data. Association for Computing Machinery, New York, NY, USA, 685–696. https://doi.org/10.1145/1989323.1989395

  2. [2]

    Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell

    Emily M. Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell. 2021. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?. InProceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency. Association for Computing Machinery, New York, NY, USA, 610–623. https://doi.org/10.1145/3442188.3445922

  3. [3]

    Tamer Özsu

    Carsten Binnig, Donald Kossmann, Eric Lo, and M. Tamer Özsu. 2007. QAGen: Generating Query-Aware Test Databases. InProceedings of the 2007 ACM SIGMOD International Conference on Management of Data. Association for Computing Machinery, New York, NY, USA, 341–352. https://doi.org/10.1145/1247480. 1247520

  4. [4]

    Hudson, Ehsan Adeli, Russ Altman, Simran Arora, Sydney von Arx, Michael S

    Rishi Bommasani, Drew A. Hudson, Ehsan Adeli, Russ Altman, Simran Arora, Sydney von Arx, Michael S. Bernstein, Jeannette Bohg, Antoine Bosselut, Emma Brunskill, et al. 2021. On the Opportunities and Risks of Foundation Models. https://doi.org/10.48550/arXiv.2108.07258 arXiv:2108.07258 [cs.LG]

  5. [5]

    Vadim Borisov, Kathrin Seßler, Tobias Leemann, Martin Pawelczyk, and Gjergji Kasneci. 2023. Language Models are Realistic Tabular Data Generators. InThe Eleventh International Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview.net. https://openreview.net/forum?id= cEygmQNOeI

  6. [6]

    Nicolas Bruno and Surajit Chaudhuri. 2005. Flexible Database Generators. In Proceedings of the 31st International Conference on Very Large Data Bases, Trond- heim, Norway, August 30 - September 2, 2005, Klemens Böhm, Christian S. Jensen, Laura M. Haas, Martin L. Kersten, Per-Åke Larson, and Beng Chin Ooi (Eds.). ACM, 1097–1107. http://www.vldb.org/archive...

  7. [7]

    Narasayya

    Bailu Ding, Surajit Chaudhuri, Johannes Gehrke, and Vivek R. Narasayya. 2021. DSB: A Decision Support Benchmark for Workload-Driven and Traditional Database Systems.Proceedings of the VLDB Endowment14, 13 (2021), 3376–3388. https://doi.org/10.14778/3484224.3484234

  8. [8]

    Google DeepMind. 2026. Gemini 3.1 Flash-Lite Model Evaluation: Approach, Methodology & Results. https://storage.googleapis.com/deepmind-media/ gemini/gemini_3-1_flash-lite_model_evaluation.pdf Published March 2026; accessed 2026-05-31

Show all 39 references
  1. [9]

    Weinberger

    Jim Gray, Prakash Sundaresan, Susanne Englert, Ken Baclawski, and Peter J. Weinberger. 1994. Quickly Generating Billion-Record Synthetic Databases.ACM SIGMOD Record23, 2 (1994), 243–252. https://doi.org/10.1145/191843.191886

  2. [10]

    Roman Heinrich, Manisha Luthra, Johannes Wehrstein, Harald Kornmayer, and Carsten Binnig. 2025. How Good are Learned Cost Models, Really? Insights from Query Optimization Tasks.Proceedings of the ACM on Management of Data3, 3 (2025), 1–27. https://doi.org/10.1145/3725309

  3. [11]

    Benjamin Hilprecht and Carsten Binnig. 2022. Zero-Shot Cost Models for Out- of-the-box Learned Cost Prediction.Proceedings of the VLDB Endowment15, 11 (2022), 2361–2374. https://doi.org/10.14778/3551793.3551799

  4. [12]

    Benjamin Hilprecht, Andreas Schmidt, Moritz Kulessa, Alejandro Molina, Kris- tian Kersting, and Carsten Binnig. 2020. DeepDB: Learn from Data, not from Queries!Proceedings of the VLDB Endowment13, 7 (2020), 992–1005. https://doi.org/10.14778/3384345.3384349

  5. [13]

    Cheng-Ping Hsieh, Simeng Sun, Samuel Kriman, Shantanu Acharya, Dima Rekesh, Fei Jia, Yang Zhang, and Boris Ginsburg. 2024. RULER: What’s the Real Context Size of Your Long-Context Language Models? https://doi.org/10. 48550/arXiv.2404.06654 arXiv:2404.06654 [cs.CL]

  6. [14]

    Mohamed Amine Ketata, David Lüdke, Leo Schwinn, and Stephan Günnemann

  7. [15]

    2013.The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling(3rd ed.)

    Ralph Kimball and Margy Ross. 2013.The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling(3rd ed.). Wiley, Hoboken, NJ, USA. https: //www.oreilly.com/library/view/the-data-warehouse/9781118530801/

  8. [16]

    Andreas Kipf, Thomas Kipf, Bernhard Radke, Viktor Leis, Peter Boncz, and Alfons Kemper. 2019. Learned Cardinalities: Estimating Correlated Joins with Deep Learning. InProceedings of the 9th Biennial Conference on Innovative Data Systems Research (CIDR 2019). CIDR, Asilomar, CA...

  9. [17]

    Skander Krid, Mihail Stoian, and Andreas Kipf. 2025. Redbench: A Benchmark Reflecting Real Workloads.CoRRabs/2506.12488 (2025). https://doi.org/10. 48550/ARXIV.2506.12488 arXiv:2506.12488

  10. [18]

    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. https://doi.org/10.14778/2850583. 2850594

  11. [19]

    Viktor Leis, Andrey Gubichev, Atanas Mirchev, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2025. Still Asking: How Good Are Query Optimizers, Really?Proceedings of the VLDB Endowment18, 12 (2025), 5531–5536. https: //doi.org/10.14778/3750601.3760521

  12. [20]

    Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang

    Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024. Lost in the Middle: How Language Models Use Long Contexts.Transactions of the Association for Computational Linguistics 12 (2024), 157–173. https://doi.org/10.116...

  13. [21]

    Eric Lo, Nick Cheng, Wilfred W. K. Lin, Wing-Kai Hon, and Byron Choi. 2014. MyBenchmark: Generating Databases for Query Workloads.The VLDB Journal 23, 6 (2014), 895–913. https://doi.org/10.1007/s00778-014-0354-1

  14. [22]

    Ryan Marcus, Parimarjan Negi, Hongzi Mao, Nesime Tatbul, Mohammad Al- izadeh, and Tim Kraska. 2021. Bao: Making Learned Query Optimization Prac- tical. InProceedings of the 2021 International Conference on Management of Data. Association for Computing Machinery, New York, NY, ...

  15. [23]

    Ryan Marcus, Parimarjan Negi, Hongzi Mao, Chi Zhang, Mohammad Alizadeh, Tim Kraska, Olga Papaemmanouil, and Nesime Tatbul. 2019. Neo: A Learned Query Optimizer.Proceedings of the VLDB Endowment12, 11 (2019), 1705–1718. https://doi.org/10.14778/3342263.3342644

  16. [24]

    Patrick O’Neil, Elizabeth O’Neil, Xuedong Chen, and Stephen Revilak. 2009. The Star Schema Benchmark and Augmented Fact Table Indexing. InPerformance Evaluation and Benchmarking. Springer Berlin Heidelberg, Berlin, Heidelberg, 237–252. https://doi.org/10.1007/978-3-642-10424-4_17

  17. [25]

    PostgreSQL Global Development Group. 2026. PostgreSQL 16 Documentation: Using EXPLAIN. https://www.postgresql.org/docs/16/using-explain.html Ac- cessed 2026-05-31

  18. [26]

    Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: An Embeddable Analyti- cal Database. InProceedings of the 2019 International Conference on Management of Data. Association for Computing Machinery, New York, NY, USA, 1981–1984. https://doi.org/10.1145/3299869.3320212

  19. [27]

    Anupam Sanghi, Shadab Ahmed, and Jayant R. Haritsa. 2022. Projection- Compliant Database Generation.Proceedings of the VLDB Endowment15, 5 (2022), 998–1010. https://doi.org/10.14778/3510397.3510398

  20. [28]

    Anupam Sanghi, Shadab Ahmed, Prashik Rawale, and Jayant R. Haritsa. 2022. Data Generation Using Join Constraints. Technical Report TR-2022-01. Database Systems Lab, Indian Institute of Science. https://dsl.cds.iisc.ac.in/publications/ report/TR/TR-2022-01.pdf

  21. [29]

    Anupam Sanghi, Rajkumar Santhanam, and Jayant R. Haritsa. 2021. Towards Gen- erating HiFi Databases. InDatabase Systems for Advanced Applications. Springer, Cham, Switzerland, 105–112. https://doi.org/10.1007/978-3-030-73194-6_8

  22. [30]

    Haritsa, and Srikanta Tirthapura

    Anupam Sanghi, Raghav Sood, Jayant R. Haritsa, and Srikanta Tirthapura. 2018. Scalable and Dynamic Regeneration of Big Data Volumes. InProceedings of the 21st International Conference on Extending Database Technology. OpenProceed- ings.org, Vienna, Austria, 301–312. https://do...

  23. [31]

    Tobias Schmidt, Viktor Leis, Peter Boncz, and Thomas Neumann. 2025. SQLStorm: Taking Database Benchmarking into the LLM Era.Proceedings of the VLDB Endowment18, 11 (2025), 4144–4157. https://doi.org/10.14778/3749646.3749683

  24. [32]

    Transaction Processing Performance Council. 2022. TPC Benchmark H (Decision Support) Standard Specification, Revision 3.0.1. https://www.tpc.org/TPC_ Documents_Current_Versions/pdf/TPC-H_v3.0.1.pdf Accessed 2026-05-25

  25. [33]

    Transaction Processing Performance Council. 2024. TPC Benchmark DS – Standard Specification, Version 4.0.0. https://www.tpc.org/TPC_Documents_ Current_Versions/pdf/TPC-DS_v4.0.0.pdf Accessed 2026-05-25

  26. [34]

    Johannes Wehrstein, Timo Eckmann, Roman Heinrich, and Carsten Binnig

  27. [35]

    Johannes Wehrstein, Roman Heinrich, Mihail Stoian, Skander Krid, Martin Stem- mer, Andreas Kipf, Carsten Binnig, and Muhammad El-Hindi. 2025. Redbench: Workload Synthesis From Cloud Traces. https://doi.org/10.48550/arXiv.2511. 13059 arXiv:2511.13059 [cs.DB] Accepted to VLDB 20...

  28. [36]

    arXiv:2507.07471

    JOB-Complex: A Challenging Benchmark for Traditional & Learned Query Optimization. arXiv:2507.07471. https://doi.org/10.48550/arXiv.2507.07471

  29. [37]

    Zheyu Zhang, Shuo Yang, Bardh Prenkaj, and Gjergji Kasneci. 2025. Not All Features Deserve Attention: Graph-Guided Dependency Learning for Tabu- lar Data Generation with Language Models. InFindings of the Association for Computational Linguistics: EMNLP 2025, Suzhou, China, No...

  30. [38]

    Shuo Yang, Zheyu Zhang, Bardh Prenkaj, and Gjergji Kasneci. 2025. Doubling Your Data in Minutes: Ultra-fast Tabular Data Generation via LLM-Induced Dependency Graphs. InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, EMNLP 2025, Suzhou, ...

  31. [2025]

    https://openreview.net/forum?id=Z3OtNSwuXX OpenReview

    Joint Relational Database Generation via Graph-Conditional Diffusion Models. https://openreview.net/forum?id=Z3OtNSwuXX OpenReview

Pith tools

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