LLVM Query Processing

Unsaid LLVM Query Processing depends on predictive CPU architecture, any inefficiency exposes security flaws in x86 (Meltdown and Spectre vulnerabilities) dealt with by limiting LLVM. We posit this strategy may impact Arc giving rise to "The Curse of Catalina" in MacOS Darwin (MacOS Slow by Design).

We wonder when Apple moves Darwin to ARM, what does this mean for others?

> Nearly all database systems will exploit multi-core architectures for inter-query parallelism, but as the number of cores available on modern CPUs increases,intra-query parallelism becomes more important.

YOUTUBE ws9TwXesv-M 2017 EuroLLVM Developers’ Meeting: Markus Eble, SAP “6 years integrating LLVM into our in-memory database"

> In principle this is a well studied problem and is usually solved by partitioning the input of operators, processing each partition independently, and then merging the results from all partitions.

Thomas Neumann, Technische University, Munich, Germany is expert in Efficiently Compiling Efficient Query Plans for Modern Hardware, we look at his paper

Supporting papers:

Indexing Highly Dynamic Hierarchical Data paper

On Supporting Hierarchical Data in Relational Main-Memory Database Systems. Jan Peter Finis Thesis

Integrating LLVM [into ABAP] deck

Also see:

L from Llang page

Volcano processing - Goetz Graefe pdf

Professor Thomas Neumann bio Database of Database HyPer


A coda we are interested in how Intel is extending its dominant architecture by way of blockchain technologies and Private Data Objects