On Feb 26, 2009, at 8:18 PM, Damien Katz wrote:
Also, he Ids don't need to be sequential (1,2,3,4...), just ordered (1,5,19,22...). And they don't need to sort higher or lower than all the other ids, so long as they are clustered together. The each btree nodes that have to be loaded that isn't in cache is expensive. The more the keys have to be inserted into random places in the btree, the worse the caching behavior. Right now, with the crypto random UUIDs we generate, it's basically the worst case scenario for doc inserts.
So why not decrease security by a tunable factor and add a random number to the previous UUID instead?
And while we're on the subject, I've wished for automatic doc UUIDs that nonetheless have a fixed prefix. More human readable plus it doubles as a type field... Any chance of that or is that one of the beginner mistakes?
Wout.
