3 ms·
If you'd done UUIDs in 1995 ( if that was even possible ) you'd have a had horrendous indexing problems, mainly relating to clustering. This was an issue when I
by thorin 3y ago
If you'd done UUIDs in 1995 ( if that was even possible ) you'd have a had horrendous indexing problems, mainly relating to clustering. This was an issue when I started using SQL Server in around 2006. Was also a concern in Oracle so I would be surprised if Postgres wouldn't have had similar problems. I think they are a non issue now though.
A discussion of some of the pros and cons:
https://stackoverflow.com/questions/11938044/what-are-the-best-practices-for-using-a-guid-as-a-primary-key-specifically-rega https://stackoverflow.com/questions/11938044/what-are-the-be...
- hot_gril 3y agoIn my experience, it's not horrendous in Postgres but still noticeably worse than bigserial. There are often reasons to have UUIDs as secondary keys. But your DB uses primary keys for disk layout, joins, etc, so I've never seen a good reason to use UUIDs there. Even the CitusDB (horizontally-scaling Postgres) examples use bigserials. I've always regretted using UUID pkeys and never regretted using bigserial. Side bonus of bigserials is you get ordering, which matters in some contexts.