Hacker News Reader

Comment by josephg | Hacker News Reader

I've got a little transactional KV store in the wings and have been thinking about writing a Go frontend for it. I'd love full SQL support, but there's no way I'm going to implement my own query optimizer. How hard would it be to repurpose this layer to back onto a generic sorted KV store?

It this deeply tied in to the rest of cockroachdb's architecture, or does it talk through a simple generic KV store interface?

View on HN

while there is an explicit delineation between the internal `kv` package[1] and the overarching `sql` one[2], your specific concern regarding a query optimizer is not strictly an isolated component at this moment in time. query optimizations, last I checked, was not an explicit pre-processing stage but rather done so when constructing the AST representation of the query with each node being an `iterator` as described in the Volcano Evaluation System paper[3]. there was some work underway to move towards an intermediate representation[4] to go through the standard query optimizations, no context into how far along this effort is.

[1]: https://github.com/cockroachdb/cockroach/tree/master/pkg/kv

[2]: https://github.com/cockroachdb/cockroach/tree/master/pkg/sql

[3]: https://paperhub.s3.amazonaws.com/dace52a42c07f7f8348b08dc2b...

[4]: https://github.com/cockroachdb/cockroach/pull/10055

I wrote the rfc for this "effort": there will be an IR in CockroachDB, just not right now. It's a lot of work and we're not going to do this in one go.

Reply on news.ycombinator.com