| |
| ▲ | debazel 4 hours ago | parent | next [-] | | 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. | | |
| ▲ | saagarjha 3 hours ago | parent [-] | | 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 | | |
| ▲ | debazel 3 hours ago | parent [-] | | If you did that you would also have to provide the timestamp every time you wanted to look up an ID, and now we're back to UUIDv7 again. | | |
| ▲ | saagarjha 3 hours ago | parent [-] | | Sure but at least you are being honest about it. For what it's worth the database can handle this internally without you needing to hand this back but if you have a bad one then yes you should probably have it give you back a location hint that you use for future queries |
|
|
| |
| ▲ | cpburns2009 4 hours ago | parent | prev [-] | | They already do. UUIDv7 neatly solves a common problem: a random, unguessable, public id that works well with databaes. UUIDv4 is infamous for this. | | |
| ▲ | saagarjha 4 hours ago | parent [-] | | This very much sounds like databases do not, in fact, support indexing on more than one thing at once. |
|
|
