3 ms·
For those interested, here's (IMO) a good explanation on why completely random UUIDs hurt performance, and can lead to database fragmentation issues down the ro
by amzans 6y ago
For those interested, here's (IMO) a good explanation on why completely random UUIDs hurt performance, and can lead to database fragmentation issues down the road (on MySQL):
https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/ https://www.percona.com/blog/2019/11/22/uuids-are-popular-bu...
It's part of what Timeflake aims to solve, but there's plenty alternatives too depending on your exact requirements.
- ForHackernews 6y agoThis is not universally true. It depends on the database engine and how its indexes are implemented.
- amzans 6y agoThanks, I updated the comment to mention that the link is in the context of MySQL's case.
- fastball 6y agoIs this applicable to postgres?
- calpaterson 6y agoIt's applicable to the indexes that postgres uses. Postgres does not put rows in the heap in order of primary key so the issue is less serious than in innodb.
- zerd 6y agoIt's pretty much true for any B-tree based index. You could get around it by using a combined index on another timestamp value, but that's going to be a very large index. Or reduce it by partitioning by e.g. year-month. Even hash-based indices would be slightly impacted due to less locality.
- deleted 6y ago[deleted]