"KSUIDs are larger than UUIDs and Flake IDs, weighing in at 160 bits. They consist of a 32-bit timestamp and a 128-bit randomly generated payload."
TTTTTTTTRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
T-Timestamp
R-Random
There are economy arguments against using this as quasi-sequential PKs.
For efficient index lookup and sorting, best is to use CPU's native register sizes.
It would be great if the PK would be a DWORD (32 bits) or QWORD (64 bits), one would assume the DB engine will align the access for efficient handling of the L1-L2 caches and prevent page tearing.
If you need to micro-optimize this way and you're 100% sure that the database engine you're using would align accesses on word boundaries, sure. Most folks will not need it.
"KSUIDs are larger than UUIDs and Flake IDs, weighing in at 160 bits. They consist of a 32-bit timestamp and a 128-bit randomly generated payload."
TTTTTTTTRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
T-Timestamp R-Random
There are economy arguments against using this as quasi-sequential PKs.
For efficient index lookup and sorting, best is to use CPU's native register sizes. It would be great if the PK would be a DWORD (32 bits) or QWORD (64 bits), one would assume the DB engine will align the access for efficient handling of the L1-L2 caches and prevent page tearing.