4 ms·
(Caveat: I know this about SQL server, not Postgres) If you use random UUID's (as opposed to sequential UUID's) for your primary key your database will spend a
by JasonPunyon 13y ago
(Caveat: I know this about SQL server, not Postgres)
If you use random UUID's (as opposed to sequential UUID's) for your primary key your database will spend an extra hunk of time on reordering your PK index on disk on insert. This bit us at Stackoverflow. So remember: just because you can do something doesn't mean you should.
- jshen 13y agoJust use a k-ordered uuid.
- labria 13y agoYepp, mentioned it here: http://labria.github.io/2013/04/28/rails-4-postgres-uuid-pk-guide/ http://labria.github.io/2013/04/28/rails-4-postgres-uuid-pk-...
- ryeguy 13y agoNo you didn't. Not fully at least. OP is saying that there is a penalty just for doing the inserts themselves.
- jashkenas 13y agoWhat's the advantage of a sequential UUID over an auto-incrementing integer? (Keeping in mind that both can be started at N on different shards, or prefixed.)
- deleted 13y ago[deleted]
- axelfontaine 13y agoYou can merge any two data buckets, without any risk of id collision.
- tszming 13y agoYes, what you said also apply to MySQL/InnoDB and MongoDB. Someone did an experiment with MongoDB some times ago for various id schemes: http://i.imgur.com/clm9D.png http://i.imgur.com/clm9D.png (https://groups.google.com/d/topic/mongodb-user/1gPqVmFHExY/discussion https://groups.google.com/d/topic/mongodb-user/1gPqVmFHExY/d...), I don't know if Postgres is being different but people should do their own testings instead of blindly listening to advices from the Internet.