Re: [PATCHES] Patch for UUID datatype (beta)

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.

In response to

Browse pgsql-hackers by date

  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?

Browse pgsql-patches by date

  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)