In response to Rob Sargent <robjsarg...@gmail.com>: > > > On 01/05/2011 08:55 AM, Bill Moran wrote: > > In response to Scott Ribe <scott_r...@elevated-dev.com>: > > > >> On Jan 5, 2011, at 8:05 AM, Bill Moran wrote: > >> > >>> Beyond that, the namespace size for a UUID is so incomprehensibly huge > >>> that the chance of two randomly generated UUIDs having the same value > >>> is incomprehensibly unlikely > >> > >> Yes, as in: it is *far* more likely that all of your team members and all > >> of your client contacts will be simultaneously struck by lightning and > >> killed in their sleep, and it is *far* more likely that all life on earth > >> will be wiped out by an asteroid impact, and it is *far* more likely that > >> the solar system orbits are not actually stable and earth will fly off > >> into space... If you're worried about UUID collisions, then either your > >> priorities are completely wrong, or you live in a bomb shelter--that's not > >> sarcasm by the way, it's simply true, the chance of a collision is so > >> vanishingly small that it is dwarfed by all sorts of risks that we all > >> ignore because the chances are so low, including the chance that all > >> drives in all your RAIDs across all your replicas will simultaneously fail > >> on the same day that fires start in all the locations where your tapes are > >> stored and all the sprinkler systems fail... (By "far" more likely, I mean > >> many many many orders of magnitude...) > > > > That statement demonstrates a lack of investigation and/or consideration > > of the circumstances. > > > > I can't find my math or I'd reproduce it here, but consider this: > > > > If you have 50 devices, each generating 100 UUIDs per hour, and you'll > > keep records for 1 year, then your argument above is probably accurate. > > > > However, if there are 5000 devices generating 100 UUIDs per hour, and you'll > > be keeping those records for 10+ years, the chances of collisions near > > the end of that 10 year span get high enough to actually make developers > > nervous. > > > > But we're talking about a primary key. Postgres guarantees the > uniqueness. 1 transaction in 10^^100 rolls back due to a second > instance of an (otherwise/almost) uuid. Big deal.
That doesn't make any sense. If you're using a single PostgreSQL instance, then why not just use the built in SERIAL mechanism that guarantees that you will NEVER have a conflict? In our case (and I expect it's the case with most people considering UUIDs) we're talking about independent devices that occasionally synchronize data between themselves. These devices need to generate a unique ID of some sort without having to check with every other device. This is one of the problems that UUIDs were intended to fix. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general