From: | Gevik Babakhani <pgdev(at)xs4all(dot)nl> |
---|---|
To: | Harald Armin Massa <haraldarminmassa(at)gmail(dot)com> |
Cc: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] Patch for UUID datatype (beta) |
Date: | 2006-09-18 09:29:03 |
Message-ID: | 1158571743.19958.40.camel@voyager.truesoftware.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Mon, 2006-09-18 at 11:11 +0200, Harald Armin Massa wrote:
> Gevik,
> >uniqueness is never a guaranteed. that is according to the RFC docs.
>
> >uniqueness is never a guaranteed in the sense that there is a tiny
> >chance someone of the other side of the planet might generate the
> same
> >guid.
>
> As much as I learned, it is recommended to give information about
> "grade of uniqueness". I think it would be a valuable information,
> which information your UUID-generator takes into account, and what the
> "grade of uniqueness" is.
>
> (I know of the Windows UUID, which takes the MAC-Address of the
> included Ethernet-Card into it's calculation, which may be guaranteed
> to be unique)
>
>
> Some more questions about UUIDs and your patch:
>
> a) compatibility of UUIDs -> I have generated a lot of UUIDs via the
> WIN32 provided function (for the unix-only-people: Windows uses UUIDs
> all around its registry, software IDs and on and on). How unique are
> those UUIDs when mixed with "your" UUIDs ?
The new_guid() generates a random guid in the range of 256^256 which is
3.231700607131100730071487668867e+616 (easy to imagine) using PG's
randomizer. I wonder how often someone could actually generate a
duplicate guid in this range. This also goes for the MS version of the
guid. It uses the MAC address and a timespamp but what happens if by
chance your PC's clock is set in the past!
>
> b) I read some time ago about the problems with UUIDs as primary keys
> in contrast to serials: serials get produced in ascending order; and
> often data which was produced in one timespan is also connected
> semantically. "near serial values" are also local within a
> btree-index; but UUIDs generated in "near times" are usually spread
> around the possible bitranges.
> (example for sequence of serials: 1 - 2 - 3 - 4 - 5 - 6
> example for sequence of UUIDs : 1 - 999919281921843191 - 782 -
> 18291831912318971231)
> that is supposed to affect the locality of the index, and from that
> also the performance of the system.
>
> I do not know how valid this information is; so I am asking you for
> your feedback; especially since you put a lot of thoughts into this
> UUID patch. Maybe you took allready care of this situation when
> constructing the index operators?
I am running many test regarding indexing of the uuid datatype with
large amount of records. But the performance test is still limited to
hardware capacity
Thank you.
>
> Thanks
>
> Harald
>
>
>
>
>
>
> --
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Reinsburgstraße 202b
> 70197 Stuttgart
> 0173/9409607
> -
> Let's set so double the killer delete select all.
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2006-09-18 10:45:21 | Re: 8.2 beta blockers |
Previous Message | Gevik Babakhani | 2006-09-18 09:12:54 | Re: UUID/GUID discussion leading to request for hexstring bytea? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-18 14:33:22 | Re: Patch for UUID datatype (beta) |
Previous Message | Harald Armin Massa | 2006-09-18 09:11:04 | Re: Patch for UUID datatype (beta) |