On 2011-01-06, Chris Browne wrote:
> (Sequence + Host Data), and I'd expect there to
> be a considerable risk of Dumb Techs making mistakes there. It wouldn't
> be difficult for such a scenario to induce systematic key collisions.
I've seen that happen. cleanup of the effected records was trick
On 6 Jan 2011, at 20:36, Chris Browne wrote:
> Infinite? The probability can't conceivably exceed 1.
Don't start picking om words please, "infinitely small" or "infinitesimal" is
obviously what I meant to write there.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
Hey guys and gals,
As the originator of this topic, I've received a lot of good answers,
opinions, and advice. Thank you.
I'm not sure that more conversation on this will go anywhere but down. It
seems that UUID vs. Integer is one of those 'values' subjects, like:
Sexual practices a
On Jan 6, 2011, at 3:52 AM, Stuart Bishop wrote:
> Maybe I should start a business in providing UUID collision insurance?
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
-M
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
In response to Chris Browne :
>
> It seems to me that using serially assigned values, along with manually
> assigned server IDs, to construct a would-be-unique value, is likely to
> introduce quite a lot *more risk* of system failure than would the use
> of UUIDs.
First off, server IDs are not ra
dal...@solfertje.student.utwente.nl (Alban Hertroys) writes:
> On 6 Jan 2011, at 17:51, Chris Browne wrote:
>
>> wmo...@potentialtech.com (Bill Moran) writes:
>> If your system is sufficiently negligently designed that this particular
>> conflict causes it to kill people, then I wouldn't be too inc
On 6 Jan 2011, at 17:51, Chris Browne wrote:
> wmo...@potentialtech.com (Bill Moran) writes:
> If your system is sufficiently negligently designed that this particular
> conflict causes it to kill people, then I wouldn't be too inclined to
> point at this issue with UUIDs being the Real Problem wi
On Jan 6, 2011, at 9:31 AM, Chris Browne wrote:
> The reasonable choices for a would-be artificial primary key seem to be
> 1 and 3; in a distributed system, I'd expect to prefer 1, as the time +
> host data are likely to eliminate the "oh, it might just randomly match"
> problem.
In some context
dennis.jenkins...@gmail.com (dennis jenkins) writes:
> The UUID itself is 128 bits. Some of those bits are pre-determined.
> I don't recall, but I think that a "normal" UUID has 121 bits of
> randomness.
That doesn't match RFC 4122 very well...
It indicates 5 forms of UUIDs:
1) Time-based, wher
wmo...@potentialtech.com (Bill Moran) writes:
> If the chance of a duplicate is 1 in a hundred gazillion, then I can
> still hit a dupe the VERY FIRST TIME I USE IT.
>
> I'm writing software that is intended to be used to save lives in the
> event of an earthquake or flood or cosmic ray flipping bi
On Wed, Jan 5, 2011 at 3:43 PM, Bill Moran wrote:
> Despite the fact that the chance of a collision is very, very small, there
> is no easy way to fix it if it happens. Zero. It can't be done without
> shutting the system down, recalling all the remote devices and manually
> reconciling the prob
On Jan 6, 2011, at 8:19 AM, Michael Satterwhite wrote:
> That would be a matter of incompetent administration. *NOTHING* can protect
> against that.
Well, no, not necessarily. It might well be a goal (in fact, is a goal with
some software that I'm developing), that users/admins don't have to wo
On Thursday 06 January 2011 7:14:00 am Bill Moran wrote:
> In response to Scott Ribe :
> > On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
> > > If you are looking at these extreme
> > > improbabilities, your SERIAL isn't guaranteed unique either when you
> > > take into account cosmic rays flippi
On Jan 6, 2011, at 8:14 AM, Bill Moran wrote:
> I don't give a fuck how small the chance of conflict is, the only
> viable option for that chance is 0. Period. Any argument to the
> contrary is stupid, asinine and outright negligent.
Do you give a fuck about the chance that bits will flip in th
In response to Scott Ribe :
> On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
>
> > If you are looking at these extreme
> > improbabilities, your SERIAL isn't guaranteed unique either when you
> > take into account cosmic rays flipping the right bits in your ECC
> > memory or on your disk platte
On Jan 6, 2011, at 1:52 AM, Stuart Bishop wrote:
> If you are looking at these extreme
> improbabilities, your SERIAL isn't guaranteed unique either when you
> take into account cosmic rays flipping the right bits in your ECC
> memory or on your disk platter.
Yes, that's rather the point, the pro
On Jan 6, 2011, at 2:51 AM, Jasen Betts wrote:
> Who was it that decided on 32 bits for IP addresses?
Nice try, but that was rather long before the IETF existed ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailin
On 2011-01-05, Scott Ribe wrote:
> On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
>
>> In practical use I think the odds of a collision are *far* higher than
>> you are suggesting, unless the UUID generation is being done with a lot
>> more care than is likely if the user takes these sorts of claims
>>> Next to that, UUID's are generated by computers. I have no doubts that
>>> the numeric space that makes up a UUID allows for collision chances as
>>> low as described, but are computers capable of generating those
>>> numbers sufficiently random that they actually achieve that low a
>>> chance?
On 6 Jan 2011, at 24:27, Chris Browne wrote:
>> Next to that, UUID's are generated by computers. I have no doubts that
>> the numeric space that makes up a UUID allows for collision chances as
>> low as described, but are computers capable of generating those
>> numbers sufficiently random that th
On Wed, Jan 05, 2011 at 07:46:18PM -0700, Scott Ribe wrote:
> And if somebody clones the disk to a new machine, but leaves the old one in
> service? Or do you use the MAC address and hope that's unique?
>
Excellent questions, and exactly the sort (as I was arguing elsewhere
in this thread) one h
On Wed, Jan 05, 2011 at 07:44:29PM -0700, Scott Ribe wrote:
> In order for a collision to matter, really in order for there to *be* a
> collision, the duplicate pair has to be collected in one place.
Not at the time of generation, though. They only have to end up in
the same place at once. Fo
On Wed, Jan 05, 2011 at 06:22:08PM -0500, Chris Browne wrote:
> But it seems to me that some of the analytics are getting a little *too*
> paranoid, on the "perhaps UUIDs are the wrong answer" side of the
> column.
That could be. I was simply noting that there are cases where one
could legitimate
On Jan 5, 2011, at 4:11 PM, Michael Satterwhite wrote:
> Each machine would have a unique machine_id. This would guarantee uniqueness
> and be very easy to maintain.
And if somebody clones the disk to a new machine, but leaves the old one in
service? Or do you use the MAC address and hope that'
On Jan 5, 2011, at 3:03 PM, Andrew Sullivan wrote:
> ...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...
In order for a collision to matter, really in order for there to *be*
a...@crankycanuck.ca (Andrew Sullivan) writes:
> 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 t
dal...@solfertje.student.utwente.nl (Alban Hertroys) writes:
>>> From wikipedia, "only after generating 1 billion UUIDs every second for
>> the next 100 years, the probability of creating just one duplicate would
>> be about 50%. The probability of one duplicate would be about 50% if
>> every perso
On 6 January 2011 00:32, dennis jenkins wrote:
> On Wed, Jan 5, 2011 at 1:03 PM, Bill Moran
> wrote:
> >
> > But the point (that you are trying to sidestep) is that the UUID
> namespace
> > is finite, so therefore you WILL hit a problem with conflicts at some
> point.
> > Just because that point
Pooled id.. child machine connects to main and says give 1 of ids,
main increments counter by 1, child allocates in given pool.
On Wed, 5 Jan 2011 17:11:35 -0600, Michael Satterwhite
wrote:
Once multiple machines are linked to maintain the database, this has
a flaw in
it as a series i
On Wed, Jan 5, 2011 at 1:03 PM, Bill Moran wrote:
>
> But the point (that you are trying to sidestep) is that the UUID namespace
> is finite, so therefore you WILL hit a problem with conflicts at some point.
> Just because that point is larger than most people have to concern themselves
> with isn
On 01/05/2011 03:39 PM, Alban Hertroys wrote:
>>> From wikipedia, "only after generating 1 billion UUIDs every second for
>> the next 100 years, the probability of creating just one duplicate would
>> be about 50%. The probability of one duplicate would be about 50% if
>> every person on earth ow
>> From wikipedia, "only after generating 1 billion UUIDs every second for
> the next 100 years, the probability of creating just one duplicate would
> be about 50%. The probability of one duplicate would be about 50% if
> every person on earth owns 600 million UUIDs."
Even if the chances of one
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 sc
On 01/05/2011 01:43 PM, Bill Moran wrote:
> In response to Rob Sargent :
>>>
>>> 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 uni
In response to Rob Sargent :
> >
> > 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 che
On 05/01/2011 19:41, Scott Ribe wrote:
to every atom in the observable universe, or 10^51 UUIDs to every
atom in the total universe using high-end estimates of the size of
the non-observable universe)?
Is that taking dark matter into account? :-)
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
On Jan 5, 2011, at 1:13 PM, Raymond O'Donnell wrote:
> Is that taking dark matter into account? :-)
It's not clear to me ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On 01/05/2011 11:57 AM, Bill Moran wrote:
> In response to Rob Sargent :
>
>>
>>
>> On 01/05/2011 08:55 AM, Bill Moran wrote:
>>> In response to Scott Ribe :
>>>
On Jan 5, 2011, at 8:05 AM, Bill Moran wrote:
> Beyond that, the namespace size for a UUID is so incomprehensibly huge
>
On Jan 5, 2011, at 12:03 PM, Bill Moran wrote:
> For crying out loud. If you're going to pick me apart with numbers, then
> actually do it with some intelligence.
If you're going to get nasty, at least try to be accurate.
> I could easily counter your argument by upping the numbers to 500,000
>
postgresql.org
Sent: Wed, January 5, 2011 2:50:11 AM
Subject: Re: [GENERAL] UUID column as pimrary key?
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
> * you have your id, before executing query, (in contrast to all this
> autoincrement) so you may put it in dependant rows
Do you mean that
On Jan 5, 2011, at 11:31 AM, Radosław Smogura wrote:
> The true is that probability
> that in two coin drops we will get two reverses is 1/4, but true is, too, as
> Newton said, it's 1/3, because if in 1st drop we don't get reverse we don't
> need to drop again.
Nonsense. You don't stop genera
In response to Scott Ribe :
> On Jan 5, 2011, at 8:55 AM, Bill Moran wrote:
>
> > That statement demonstrates a lack of investigation and/or consideration
> > of the circumstances.
>
> No, it doesn't.
>
> > However, if there are 5000 devices generating 100 UUIDs per hour, and you'll
> > be keep
In response to Rob Sargent :
>
>
> On 01/05/2011 08:55 AM, Bill Moran wrote:
> > In response to Scott Ribe :
> >
> >> 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 U
Scott Ribe Wednesday 05 January 2011 17:33:51
> On Jan 5, 2011, at 9:19 AM, Leif Biberg Kristensen wrote:
> > I can't help thinking of the «Birthday Paradox»:
> Yes, the calculation of the probability of a collision is the same for the
> "birthday paradox" as for random UUID collisions.
Depends o
On Jan 5, 2011, at 10:30 AM, Radosław Smogura wrote:
> 128bits is huge for now, but what will happen in next 2,3 years?
It will still be large. When you get up to around 100 trillion UUIDs, you'll be
getting up to around a 1 in a billion chance of a single collision. Before you
claim that we'll
Original Message
Subject: Re: [GENERAL] UUID column as pimrary key?
Date: Wed, 5 Jan 2011 10:11:49 -0700
From: Scott Ribe
To: Adrian Klaver
On Jan 5, 2011, at 9:57 AM, Adrian Klaver wrote:
Maybe or maybe not:)
So... If you choose to use a name-based UUID, *and* you do a
Sorry for not citation...
When I was talking about "almost unique", I was meaning that the UUID is
random so there is no guarantee that you will not generate two indencital
UUIDs even in subsequent calls, but it has low probability (you have
greater chances to win in LOTTO).
128bits is hug
On 01/05/2011 08:29 AM, Scott Ribe wrote:
On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
In practical use I think the odds of a collision are *far* higher than
you are suggesting, unless the UUID generation is being done with a lot
more care than is likely if the user takes these sorts of claims a
On Wed, Jan 5, 2011 at 3:03 PM, Mike Christensen wrote:
> 2011/1/5 Grzegorz Jaśkiewicz :
>> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
>> wrote:
>>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>>
* simple to generate, and 128bit random is almost globally unique,
>>>
>>> Almost? Sho
On Jan 5, 2011, at 9:19 AM, Leif Biberg Kristensen wrote:
> I can't help thinking of the «Birthday Paradox»:
Yes, the calculation of the probability of a collision is the same for the
"birthday paradox" as for random UUID collisions.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevate
On Jan 5, 2011, at 9:01 AM, Tom Lane wrote:
> In practical use I think the odds of a collision are *far* higher than
> you are suggesting, unless the UUID generation is being done with a lot
> more care than is likely if the user takes these sorts of claims at face
> value.
Eh? The user taking su
On Wednesday 5. January 2011 16.05.29 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 ... it is, however, not a 100% guarantee.
I can't help thinking
On Jan 5, 2011, at 8:55 AM, Bill Moran wrote:
> That statement demonstrates a lack of investigation and/or consideration
> of the circumstances.
No, it doesn't.
> However, if there are 5000 devices generating 100 UUIDs per hour, and you'll
> be keeping those records for 10+ years, the chances of
On 01/05/2011 08:55 AM, Bill Moran wrote:
> In response to Scott Ribe :
>
>> 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 incomprehensib
Scott Ribe writes:
> 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 y
In response to Scott Ribe :
> 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 lik
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 o
On Jan 5, 2011, at 8:03 AM, Mike Christensen wrote:
> As long as all your UUIDs are generated with the same algorithm, they
> are guaranteed to be unique.
There is no requirement that they be generated with the same algorithm in order
to be unique. A MAC/time-based UUID cannot duplicate a random
In response to Scott Ribe :
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
> > * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
This is going off-topic, but I did some research o
On Jan 5, 2011, at 7:55 AM, Grzegorz Jaśkiewicz wrote:
> But I would never rely on that alone. You always have a strategy in
> place, in case there's a duplicate.
That's really unnecessary, basically a total waste of effort.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
2011/1/5 Grzegorz Jaśkiewicz :
> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
> wrote:
>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>
>>> * simple to generate, and 128bit random is almost globally unique,
>>
>> Almost? Should be totally unique, as long as your random source is decent
>>
On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe wrote:
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
>> * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
But I would never rely on that
On Jan 5, 2011, at 7:28 AM, Radosław Smogura wrote:
> It's simpler to write:
...
> isn't it?
Depends on the situation, the libraries you're using, and so on.
Now, if you're generating records in a distributed system, where your node
might be disconnected when it's creating a record, it is *much
On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
> * simple to generate, and 128bit random is almost globally unique,
Almost? Should be totally unique, as long as your random source is decent
quality.
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voic
On 5 January 2011 15:28, Radosław Smogura wrote:
> On Wed, 05 Jan 2011 21:50:11 +1100, Craig Ringer <
> cr...@postnewspapers.com.au> wrote:
>
>> On 01/05/2011 07:31 PM, Radosław Smogura wrote:
>>
>> * you have your id, before executing query, (in contrast to all this
>>> autoincrement) so you ma
On Wed, 05 Jan 2011 21:50:11 +1100, Craig Ringer
wrote:
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
* you have your id, before executing query, (in contrast to all this
autoincrement) so you may put it in dependant rows
Do you mean that with a UUID, you don't need to talk to the database
On 01/05/2011 07:31 PM, Radosław Smogura wrote:
* you have your id, before executing query, (in contrast to all this
autoincrement) so you may put it in dependant rows
Do you mean that with a UUID, you don't need to talk to the database at
all, you can generate an ID with no interaction with
On Tue, 4 Jan 2011 11:07:00 -0800 (PST), Dennis Gearon
wrote:
I haven't been able to find anywhere, easily, in the documentation
using google
where a list of allowed data types for primary keys is.
So, UUIDs can be primary keys?
Any issues wtih them on sorting or paging of index tables, etc.?
d.w...@computer.org (David Wall) writes:
> We're using UUID for primary keys in PG 8.4 without any issues. I
> have no real insights into the details or performance issues, but
> always figured it was stored as a binary 128-bit value, but with added
> benefits of being able to enter and view them
We're using UUID for primary keys in PG 8.4 without any issues. I have
no real insights into the details or performance issues, but always
figured it was stored as a binary 128-bit value, but with added benefits
of being able to enter and view them using a standard string format. We
don't sor
On Tue, 2011-01-04 at 11:07 -0800, Dennis Gearon wrote:
> I haven't been able to find anywhere, easily, in the documentation using
> google
> where a list of allowed data types for primary keys is.
Anything that can be UNIQUE NOT NULL
>
> So, UUIDs can be primary keys?
Yes.
JD
--
PostgreS
I haven't been able to find anywhere, easily, in the documentation using google
where a list of allowed data types for primary keys is.
So, UUIDs can be primary keys?
Any issues wtih them on sorting or paging of index tables, etc.?
Also, the documentation says that UUIDs are 128 bit value, but n
72 matches
Mail list logo
