Live data from Hacker News

Snel: SQL Native Execution for LLVM

arxiv.org

1–10 of 29 posts

Re: Snel: SQL Native Execution for LLVM

#3
post #2

I don’t know if it is intended but “snel” is the Dutch translation of “fast”

It is.

We called this new engine “SNEL” as an acronym for “SQL Native Execution for LLVM”. Well, that’s the excuse, actually we chose Snel because that means “fast” in Dutch and the name seemed right to us. from https://arxiv.org/pdf/2002.09449.pdf#page=6

Re: Snel: SQL Native Execution for LLVM

#6

Sounds pretty much what Postgres is doing since v11

Actually this is quite a bit different. This is more a columnar-store version of SQLite, basically an embedded OLAP database, which is pretty cool. I’m not aware of other column-stores in this niche, most are distributed systems meant for big data and so are much more complicated to setup and manage.

Re: Snel: SQL Native Execution for LLVM

#8
post #5

I understand SQL, and I kind of understand LLVM, but I don't understand why SQL on LLVM?

Most SQL engines implement the query engine as a virtual machine that traverses the result on a row by row basis, under the presumption that I/O is the bottleneck. In other words, this is very slow on modern hardware.

Re: Snel: SQL Native Execution for LLVM

#9
post #5

I understand SQL, and I kind of understand LLVM, but I don't understand why SQL on LLVM?

It's not completely uncommon for SQL code execution, especially in complicated legacy systems, to become a performance bottleneck. You normally think of data access being the resource the server is trying to manage, but occasionally it needs to churn on that data as its querying it (because the computed values can't be stored for some crazy reason). In such situations, it would surely be nice to have SQL code itself able to access low level optimizations.
Post reply on HN