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 →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
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.
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
- 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.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
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)
- [§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.
- [§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.
- [§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.
- [§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)
- [§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.
- [§1 Introduction] Typo in 'it has beenthedataset for learned-cardinality...' — missing spaces and article.
- [§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.
- [§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
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
free parameters (3)
- Selection-weight factors w_pop, w_fit, w_cap, w_latent, w_graph, w_policy =
Not reported
- Workload-specific PG cost-to-ms geometric-mean scale =
Per workload (JOB-Light / JOB / JOB-Complex), values not given
- Generation profile (primary-movie count, years, entity-pool sizes, seed) =
200,000 primary movies; years approximately 2022-2050 (Fig. 1); seed value not stated
assumptions (4)
- domain assumption LLM-generated priors are a valid proxy for the semantic coupling structure of IMDb attributes.
- domain assumption The temporal signed graph's edge/evolution semantics generate join-relevant correlations similar to IMDb's.
- domain assumption The canonical PostgreSQL IMDb schema and JOB-family templates transfer to the synthetic instance.
- domain assumption Gemini 3.1 Flash-Lite Preview outputs are parseable, normalized, versioned, and fully captured in the released provenance.
invented entities (2)
-
LLM world-building latent variables (movie profile z_m, signed-edge type/strength/provenance, latent deltas)
independent evidence
-
Temporal signed graph with type-2 SCD edge versions
independent evidence
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
Reference graph
Works this paper leans on
-
[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
arXiv 2011
-
[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
arXiv 2021
-
[3]
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]
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]
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
2023
-
[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...
2005
- [7]
-
[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
2026
Show all 39 references
-
[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
1994
-
[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
2025 doi
-
[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
2022
-
[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
2020
- [13]
-
[14]
Mohamed Amine Ketata, David Lüdke, Leo Schwinn, and Stephan Günnemann
-
[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/
2013
-
[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...
2019
- [17]
-
[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
2015 doi
-
[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
2025
-
[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...
2024 doi
-
[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
2014 doi
-
[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, ...
2021
-
[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
2019
-
[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
2009 doi
-
[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
2026
-
[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
2019
-
[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
2022
-
[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
2022
-
[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
2021 doi
-
[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...
2018 doi
-
[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
2025
-
[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
2022
-
[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
2024
-
[34]
Johannes Wehrstein, Timo Eckmann, Roman Heinrich, and Carsten Binnig
- [35]
- [36]
-
[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...
2025 doi
-
[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, ...
2025 doi
-
[2025]
https://openreview.net/forum?id=Z3OtNSwuXX OpenReview
Joint Relational Database Generation via Graph-Conditional Diffusion Models. https://openreview.net/forum?id=Z3OtNSwuXX OpenReview
Reviewed August 1, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.