Extending SQL to Return a Subdatabase
Joris Nix, Jens Dittrich
Abstract
Every SQL statement is limited to return a single, possibly denormalized table. This approximately 50-year-old design decision has far-reaching consequences. The most apparent problem is the redundancy introduced through denormalization, which can result in long transfer times of query results and high memory usage for materializing intermediate results. Additionally, regardless of their goals, users are forced to fit query computations into one single result, mixing the data retrieval and transformation aspect of SQL. Moreover, both problems violate the principles and core ideas of normal forms. In this paper, we argue for eliminating the single-table limitation of SQL. We extend SQL's SELECT clause by the keyword 'RESULTDB' to support returning a result subdatabase. Our extension has clear semantics, i.e., by annotating any existing SQL statement with the RESULTDB keyword, the DBMS returns the tables participating in the query, each restricted to the relevant tuples that occur in the traditional single-table query result. Thus, we do not denormalize the query result in any way. Our approach has significant, far-reaching consequences, impacting the querying of hierarchical data, materialized views, and distributed databases, while maintaining backward compatibility. In addition, our proposal paves the way for a long list of exciting future research opportunities. We propose multiple algorithms to integrate our feature into both closed-source and open-source database systems. For closed-source systems, we provide several SQL-based rewrite methods. In addition, we present an efficient algorithm for cyclic and acyclic join graphs that we integrated into an open-source database system. We conduct a comprehensive experimental study. Our results show that returning multiple individual result sets can significantly decrease the result set size. Furthermore, our rewrite methods and algorithm introduce minimal overhead and can even outperform single-table execution in certain cases.
Ask about this paper
Your agent reads all of it.
Lune indexed this paper to the last equation, along with the top-tier papers that cite it. Ask a question and the answer quotes them.
Cited by top-tier papers1
Ask how each one uses itBuilds on5
- The LDBC Social Network Benchmark: Business Intelligence WorkloadGábor Szárnyas, Jack Waudby, Benjamin A. Steer, Dávid Szakállas et al.VLDB 2023 · 103 citations
- Adopting Worst-Case Optimal Joins in Relational Database SystemsMichael J. Freitag, Maximilian Bandle, Tobias Schmidt, Alfons Kemper et al.VLDB 2020 · 79 citations
- Bitvector-aware Query Optimization for Decision Support QueriesBailu Ding, Surajit Chaudhuri, Vivek R. NarasayyaSIGMOD 2020 · 21 citations
- Free Join: Unifying Worst-Case Optimal and Traditional JoinsYisu Remy Wang, Max Willsey, Dan SuciuSIGMOD 2023 · 18 citations
- Efficiently Computing Join Orders with Heuristic SearchImmanuel Haffner, Jens DittrichSIGMOD 2023 · 8 citations
Related papers
- Ranked Enumeration of Join Queries with ProjectionsShaleen Deep, Xiao Hu, Paraschos KoutrisVLDB 2022 · 14 citations
- Benchmarking the Full Pipeline of Materialized-View-Based Query RewritingXinjie Hu, Zhengjie MiaoVLDB 2026
- Debunking the Myth of Join Ordering: Toward Robust SQL AnalyticsJunyi Zhao, Kai Su, Yifei Yang, Xiangyao Yu et al.SIGMOD 2025 · 13 citations
- Chimera: A system design of dual storage and traversal-join unified query processing for SQL/PGQGeonho Lee, Jeongho Park, Min-Soo KimVLDB 2025 · 4 citations
- Decomposition-Driven Multi-Table Retrieval and Reasoning for Numerical Question AnsweringFeng Luo, Hai Lan, Hui Luo, Zhifeng Bao et al.ICDE 2026 · 1 citation
