radub

4 ms·

1.
by radub 6y ago
Hi, regarding number 3, I have filed https://github.com/cockroachdb/cockroach/issues/58032 . Would love to get your feedback on the proposal; does it address your need? do you have a different idea for how it
2.
by radub 6y ago
There are quite a few case studies / customer stories on the website: https://www.cockroachlabs.com/customers/
3.
by radub 8y ago
We plan to support cardinality estimations for multiple columns. Other than that there are no plans for multivariate stats in the near future.
4.
by radub 8y ago
[Cockroach Labs engineer here, I worked on statistics] All table statistics are stored in a system table (system.table_statistics). CREATE STATISTICS scans the table, calculating statistics on a column, and adds a new row to system.table_st
5.
by radub 9y ago
I don't have a specific timeline but it is something we will be focusing on in the following releases. Regarding DDL statements, this blog post [1] has details. In a nutshell, online schema changes are possible; the changes become visi
6.
by radub 10y ago
http://morgana249.blogspot.com/2014/10/images-of-most-beauti...
7.
by radub 10y ago
Thanks! Yes, I expect we will be moving in that direction before too long. It will work well with log tags which are already key-values. Plus most of our messages make it into traces and OpenTracing is switching to a KV interface as well.
8.
by radub 10y ago
In the majority of cases, the current layer would have added a log tag to the Context, so looking up the log tags structure will be immediate. On the other hand, we also use OpenTracing and we do have to go through the hierarchy to find the
9.
by radub 10y ago
It could be great exposure therapy :)
10.
by radub 10y ago
[cockroach labs engineer here] Where are you getting the "ignoring stability" part? Or that we "skipped correctness and stability" (in another comment of yours)? Correctness and robustness are the main factors behind the
11.
by radub 10y ago
The relevant tests fall somewhere between unit tests and integration tests. Many are intended as unit tests, but we prefer to test them on top of the "real" implementations of the layers underneath (instead of mocks) so they are i
12.
by radub 10y ago
Thank you! Making everything public runs the risk of other modules using internal implementation details, and that entanglement makes changing things a lot harder. For a small project where you can easily control this, it's likely not
13.
by radub 10y ago
The sql module needs other aspects of the server set up to function (e.g. the KV layer). You are free to browse the code at https://github.com/cockroachdb/cockroach if you want a more in-depth look.