Precision performance surgery for CostgreSQL

Modern location-based applications rely extensively on the ecient processing of spatial data and queries. Spatial query engines are commonly engineered as an extension to a relational database or a cluster-computing framework. Large parts of the spatial processing runtime is spent on evaluating spatial predicates and traversing spatial indexing structures. Typical high-level implementations of these spatial structures incur signicant interpretive overhead, which increases latency and lowers throughput. A promising idea to improve the performance of spatial workloads is to leverage native code generation techniques that have become popular in relational query engines. However, architecting a spatial query compiler is challenging since spatial processing has fundamentally dierent execution characteristics from relational workloads in terms of data dimensionality, indexing structures, and predicate evaluation.In this paper, we discuss the underlying reasons why standard query compilation techniques are not fully eective when applied to spatial workloads, and we demonstrate how a particular style of query compilation based on techniques borrowed from partial evaluation and generative programming manages to avoid most of these diculties by extending the scope of custom code generation into the data structures layer. We extend the LB2 main-memory query compiler, a relational engine developed in this style, with spatial data types, predicates, indexing structures, and operators. We show that the spatial extension matches the performance of specialized library code and outperforms relational and map-reduce extensions.

show abstract

“…al. [21] compiles query subexpressions into machine code. The work in [58] uses program specialization and LLVM to generate query code.…”

Section: Related Workmentioning

confidence: 99%

Architecting a Query Compiler for Spatial Workloads

Tahboub

Rompf

2020

Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data

View full text Add to dashboard Cite

show abstract

“…Weld [50] provides a common runtime for diverse libraries (e.g., SQL and machine learning). Butterstein et al [19] compile query subexpressions into machine code in PostgreSQL. Similarly, the work in [62] uses program specialization and LLVM to generate query code in Postgres.…”

Section: Related Workmentioning

confidence: 99%

Towards compiling graph queries in relational engines

Tahboub

Essertel

et al. 2019

Proceedings of the 17th ACM SIGPLAN International Symposium on Database Programming Languages

View full text Add to dashboard Cite

The increasing demand for graph query processing has prompted the addition of support for graph workloads on top of standard relational database management systems (RDBMS). Although this appears like a good idea-after all, graphs are just relations-performance is typically suboptimal since graph workloads are naturally iterative and rely extensively on efficient traversal of adjacency structures that are not typically implemented in an RDBMS. Adding such specialized adjacency structures is not at all straightforward due to the complexity of typical RDBMS implementations. The iterative nature of graph queries also practically requires a form of runtime compilation and native code generation which adds another dimension of complexity to the RDBMS implementation and any potential extensions. In this paper, we demonstrate how the idea of the first Futamura projection, which links interpreted query engines and compilers through specialization, can be applied to compile graph workloads in an efficient way that simplifies the construction of relational engines which also support graph workloads. We extend the LB2 main-memory query compiler with graph adjacency structures and operators. We implement a subset of the Datalog logical query language evaluation to enable processing graph and recursive queries efficiently. The graph extension matches, and sometimes outperforms, best-of-breed low-level graph engines.

show abstract