Re: UUID column as pimrary key? - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: UUID column as pimrary key?
Date
Msg-id 20110105220311.GE19652@shinkuro.com
Whole thread Raw
In response to Re: UUID column as pimrary key?  (Scott Ribe <scott_ribe@elevated-dev.com>)
Responses Re: UUID column as pimrary key?
Re: *****SPAM***** Re: UUID column as pimrary key?
List pgsql-general
On Wed, Jan 05, 2011 at 12:41:43PM -0700, Scott Ribe wrote:
> I'm not sidestepping the point at all.

You may be missing it, however, because. . .

> The point is that the finiteness of the space is a red herring. The
> space is large enough that there's no chance of collision in any
> realistic scenario.
> In order to get to a point where the probability
> of collision is high enough to worry about, you have to generate
> (and collect) UUIDs at a rate that is simply not realistic--as in
> your second example quoted above.

. . .the example was not that UUIDs are being generated and collected
in one place at that rate, but that they're being generated in several
independent places at a time, and if the cost of the collision is
extremely high, there might be reasons not to use the UUID strategy
but instead to use something else that is generated algorithmically by
the database.  There's a trade-off in having distributed systems
acting completely independently, and while I have lots of confidence
in my colleagues at the IETF (and agree with you that for the
overwhelming majority of cases UUIDs are guaranteed-unique enough),
correctly making these trade-offs still requires thought and
analysis.  It's exactly the kind of of analysis that professional
paranoids like DBAs are for.

A

--
Andrew Sullivan
ajs@crankycanuck.ca

pgsql-general by date:

Previous
From: Rob Sargent
Date:
Subject: Re: UUID column as pimrary key?
Next
From: Peter Geoghegan
Date:
Subject: Re: Asynchronous queries with bound data.