Comment by cpburns2009
18 hours ago
The point of shoving the timestamp into it is to make it work well with database indexes. UUIDv4 is awful in that regard.
18 hours ago
The point of shoving the timestamp into it is to make it work well with database indexes. UUIDv4 is awful in that regard.
Sounds like the problem here is that databases need to index on more than one thing at once
They already do. UUIDv7 neatly solves a common problem: a random, unguessable, public id that works well with databaes. UUIDv4 is infamous for this.
This very much sounds like databases do not, in fact, support indexing on more than one thing at once.
1 reply →
It doesn’t have anything to do with indexing more than one thing.
The issue with truly random IDs is that inserts are scattered throughout the B-tree index, which cause page splits, fragmentation, and poor cache locality. Using a timestamp prefix makes new IDs sequential, so inserts tend to land near the end of the index, which avoid all the B-tree trashing and improve write performance.
Yes, which means that you should probably be able to provide your timestamp to the database so it can use it for optimizing its index, rather than trying to shove it in your ID
3 replies →