10 ms·

I'll read up on that, thanks for pointing these things out. One question though, doesn't CockroachDB also have a holdout period of 250ms (default) when reading

I'll read up on that, thanks for pointing these things out. One question though, doesn't CockroachDB also have a holdout period of 250ms (default) when reading across shards, kind of similar to Spanner's 7ms holdout on writes? I remember reading something vaguely similar to that somewhere.

thanatos_dem 7y ago
As far as I’m aware there is no explicit holdout period on reads, however, on read you do need quorum of the range holders for consistency sake. The exception here is if you’re talking to the “leaseholder” of that data, in which case it can respond to you directly. If you have a workflow that consistently exercises the same ranges, leaseholders will be moved to the nodes that you’re connected to, in a process called “follow the workload”. If you run a load generator against a cluster you’ll see that - for the first 30-90 seconds or so it’ll have some latency, but after some period of time, the leases should be moved closer to your generator and you should see latencies drop. When you’re looking at data access patterns and partitioning you should keep this in mind, as it can be a big performance improvement if properly considered.