Viewing profile — petermattis
petermattis
HN member- Joined
- Wed, Mar 25, 2015, 11:48 PM UTC
- HN karma
- 90
- Public activity
- 15 items
- HN profile
- View on Hacker News ↗
About petermattis
No profile information was provided.
Recent public activity
-
comment
Comment #24496181
Cgo exists because goroutine stacks are small and grow on demand. C/C++ expect large fixed size stacks. While you can technically call into C++ without going through cgo (see https…
-
comment
Comment #24491779
Direct IO is on our radar, though when I experimented with enabling direct IO in RocksDB it only hurt CockroachDB benchmarks. This was several years ago. I believe newer releases o…
-
comment
Comment #24488279
> Is Pebble/CockroachDB capable of saturating the backplane with requests in parallel? Yes. > Does it multiplex a single query by dispatching smaller requests to a thread-pool? Yes…
-
comment
Comment #24487915
Pebble and FoundationDB are apples and oranges. Pebble is per-node KV storage engine. FoundationDB is a distributed multi-modal database. Internally, FoundationDB uses a library li…
-
comment
Comment #24487879
Yes. So far performance was worse in experiments, and the durability improvements are questionable because it is extremely difficult to get a clear understanding of the durability …
-
comment
Comment #24487855
Damned for using a unique name (CockroachDB), and damned for using an innocuous one. PS PebblesDB was a research project and is dead as far as I know.
-
comment
Comment #24487755
Pebble does not currently implement MultiGet as CockroachDB did not use RocksDB's MultiGet operation. CockroachDB can use multiple nodes to process a query by decomposing SQL queri…
-
comment
Comment #24487689
As far as I'm aware, the fsync/fdatasync sharp edges are around what happens after an fsync/fdatasync failure. My understanding is that you can't rely on anything. The only sane op…
-
comment
Comment #24486711
> So I understand the rationale for writing your own storage layer and think this is an awesome project, but there's something missing for me. One of the issues Peter brings up is …
-
comment
Comment #24486244
The TLDR is that the GC did cause problems so we had to avoid it for the block cache. Luckily we were able to do so without exposing the complexity in the API. Not for the faint of…
-
comment
Comment #14243362
Performance is "ok". CockroachDB 1.0 won't be winning benchmarks, but that was never the goal. We have seen near linear scaling from 3-64 nodes on a uniformly random write workload…
-
comment
Comment #14243301
(Cockroach Labs co-founder here) This is a really hard question to answer because there are so many different scenarios to test. Even if you restrict the question to KV operations …
-
comment
Comment #14243052
(Cockroach Labs co-founder here) CockroachDB also stores SQL metadata inside of the KV store, but that metadata is also gossiped around the cluster (i.e. it is replicated to every …
-
comment
Comment #11636152
Hi Chris, we describe CockroachDB as a SQL database because that is what we're aspiring to. The missing functionality (i.e. joins) is on our near-term roadmap.
-
comment
Comment #11633322
(employee/founder here) Re joins: we have top men working on it right now. Joins are definitely an interesting problem for a distributed database.