How We Built a Vectorized SQL Engine
cockroachlabs.com
How We Built a Vectorized SQL Engine
1–10 of 56 posts
Re: How We Built a Vectorized SQL Engine
#2A few Cockroach Labs engineers are hanging out on this thread - happy to answer any questions you might have about how we made Go go faster.
Re: How We Built a Vectorized SQL Engine
#3This is such a great post! Soooo many databases have implemented some kind of “column store extension” where they change the on disk representation and declare “look now we’re a hybrid database”. But the academic literature suggests that the bigger win for column stores may be in the execution layer. I love that Cockroach has taken the opposite of the usual approach and been so rigorous in measuring everything.
After doing all this work, is it your opinion that (hypothetically) a columnar on-disk representation would be a bigger or smaller win than a fully-built-our vectorized execution engine?
Re: How We Built a Vectorized SQL Engine
#4Didn't CockroachDB target OLTP workloads? What would the write performance be like for a columnar store for OLTP workload?
Re: How We Built a Vectorized SQL Engine
#5A few Cockroach Labs engineers are hanging out on this thread - happy to answer any questions you might have about how we made Go go faster.
does Go's compiler emit SIMD instructions? it'd be cool to see the disassembly for the final, column order version since that loop would vectorize well. the same question goes for the speed-of-light benchmark -- there may be room to push even further there if it's doing a single multiply at a time.
Re: How We Built a Vectorized SQL Engine
#6A few Cockroach Labs engineers are hanging out on this thread - happy to answer any questions you might have about how we made Go go faster.
does Go's compiler emit SIMD instructions? it'd be cool to see the disassembly for the final, column order version since that loop would vectorize well. the same question goes for the speed-of-light benchmark -- there may be room to push even further there if it's doing a single multiply at a time.
It does not. You can use something like Avo to lighten the load a bit of writing those assembly routines. It takes care of register allocation, struct fields, and the necessary function stubs.
Re: How We Built a Vectorized SQL Engine
#7Earlier quoted context omitted.
does Go's compiler emit SIMD instructions? it'd be cool to see the disassembly for the final, column order version since that loop would vectorize well. the same question goes for the speed-of-light benchmark -- there may be room to push even further there if it's doing a single multiply at a time.
It does not. You can use something like Avo to lighten the load a bit of writing those assembly routines. It takes care of register allocation, struct fields, and the necessary function stubs.
+1 avo is on our radar as a tool to use in the future
Re: How We Built a Vectorized SQL Engine
#8Didn't CockroachDB target OLTP workloads? What would the write performance be like for a columnar store for OLTP workload?
CockroachDB does target OLTP workloads. Note that the vectorized SQL engine covered in this blog post is execution-only (and used only for queries that operate on many rows). The storage layer remains row-oriented so the write performance is not affected. Rows are columnarized before processing by the execution engine.
Re: How We Built a Vectorized SQL Engine
#9This is such a great post! Soooo many databases have implemented some kind of “column store extension” where they change the on disk representation and declare “look now we’re a hybrid database”. But the academic literature suggests that the bigger win for column stores may be in the execution layer. I love that Cockroach has taken the opposite of the usual approach and been so rigorous in measuring everything. After…
> "data needs to be read from disk in its original row-oriented format before processing, which will account for the lion’s share of the query’s execution latency."
IO is still a bottleneck without column-stores. The selectivity, compression and encoding alone can generate massive speedups because there's less data to process, and less to move through the execution pipeline.
But batch/vectorized processing on row-stores is gaining adoption. MemSQL and SQL Server also use similar techniques.
Re: How We Built a Vectorized SQL Engine
#10This is such a great post! Soooo many databases have implemented some kind of “column store extension” where they change the on disk representation and declare “look now we’re a hybrid database”. But the academic literature suggests that the bigger win for column stores may be in the execution layer. I love that Cockroach has taken the opposite of the usual approach and been so rigorous in measuring everything. After…
Thanks! I do think that a columnar on-disk representation would likely help with large analytical queries. But I would imagine they would negatively affect performance of point transactions in an OLTP workload. Note that this vectorized engine we built will only be used on a given query if our SQL planner estimates that a large number of rows will be read.