Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
Date
Msg-id CABRT9RA+1N0stmHQRt3d4Zp0Rm_9gFStCLfHw2VVM16QWGm6bQ@mail.gmail.com
Whole thread Raw
In response to Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table  (Josh Berkus <josh@agliodbs.com>)
Responses Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table
List pgsql-hackers
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus <josh@agliodbs.com> wrote:
> A pseudo-random UUID is frankly pretty
> useless to me because (a) it's not really unique

This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
long as you can trust the random number generator, the chances of a
value occurring twice can be estimated using the birthday paradox:
there's a 50% chance of having *one* collision in a set of 2^61 items.
Storing this amount of UUIDs alone requires 32 exabytes of storage.
Factor in the tuple and indexing overheads and you'd be needing close
to all the hard disk space ever manufactured in the world.

If you believe there's a chance of ever seeing a pseudorandom UUID
collision in practice, you should be buying lottery tickets.

To the contrary. Combined with the fact that pseudorandom UUID
generation doesn't require any configuration (node ID), doesn't leak
any private data (MAC address) and relies on infrastructure that's
ubiquitous anyway (cryptographic PRNG) it's almost always the right
answer.

> (b) it doesn't help me route data at all.

That's really out of scope for UUIDs. They're about generating
identifiers, not describing what the identifier means. UUIDs also
don't happen to cure cancer.

Regards,
Marti



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Composite Datums containing toasted fields are a bad idea(?)
Next
From: Tom Lane
Date:
Subject: Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table