# Keyspace partitions & performance **URL:** https://forums.foundationdb.org/t/keyspace-partitions-performance/168 **Category:** Using FoundationDB **Created:** [April 21, 2018, 5:03am UTC](https://forums.foundationdb.org/t/keyspace-partitions-performance/168 "2018-04-21T05:03:54Z") **Posts on this page:** 1 **Showing post:** 7
### Author: ![alloc](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alloc/32/9_2.png) [@alloc](https://forums.foundationdb.org/u/alloc) #### Post date: [April 22, 2018, 2:56am UTC](https://forums.foundationdb.org/t/keyspace-partitions-performance/168/7 "2018-04-22T02:56:50Z")
The million versions a second thing is controlled by the `VERSIONS_PER_SECOND` knob, specified in [Knobs.cpp](https://github.com/apple/foundationdb/blob/cd55021baf85ad127832d31bbd5877df8c53d96b/fdbserver/Knobs.cpp#L59). Because it is a “knob”, you can actually change it by passing different flags to fdbserver processes. For example, you could pass `--knob_versions_per_second=100` to fdbserver on startup, and then it will only advance the commit version by 100 every second instead of 1,000,000. We regularly do stuff like this in simulation to test whether we really can change knobs. I also wanted to mention this because it is part of the internals of the database, so relying on its behavior as a kind of fuzzy clock (for example) could be dangerous, and it could theoretically change in a future release without a lot of warning (because it is outside the contract of the database). The only guarantee we do provide about versions is that it will monotonically increase with time, i.e., that after we have committed a version `v`, all transactions that begin after the commit time of `v` will be assigned a read version greater than or equal to `v`. This guarantees what we call causality and what many people call linearizability. --- _[View the full topic](https://forums.foundationdb.org/t/keyspace-partitions-performance/168)._