Re: TODO item: GUID

From: mark(at)mark(dot)mielke(dot)cc
To: Aleksandar Dezelin <dezelin(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: TODO item: GUID
Date: 2006-09-09 22:03:17
Message-ID: 20060909220316.GA32672@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 09, 2006 at 07:47:19PM +0200, Aleksandar Dezelin wrote:
> Hello,
> you just have to make random 128 bits and set version bits. And that's all.

> This is the way this data type is implemented in Mono
> (http://svn.myrealbox.com/source/trunk/mcs/class/corlib/System/Guid.cs).
>
> Using time based GUIDs in database tables is not a good choice for
> performance reasons because they can not be indexed properly - every newly
> created time-based GUID is guaranteed to be larger than all previously
> created, so RDBMS engine must re balance b-tree every time a new GUID item
> is added to data table.
>
> Sorry, for sending this message three times - problem with Gmail.

Depends how badly you want to skew the odds that a newly generated ID
is actually new, and how much you trust the distribution of your random
number generator.

There are several ways to generate a UUID - and I think it is wrong to
say that only one is the right way. Different applications choose
different generation routines. I *like* sorting by time, as it allows
the UUID to be used similar to sequence, leaving older, lesser accessed
UUIDs in the past. You and Mono might prefer something else. Some choose
random numbers over the MAC address as well - better? Depends on how big
your system is.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Kronuz 2006-09-09 22:13:51 ISBN/ISSN/ISMN/EAN13 module
Previous Message Marc G. Fournier 2006-09-09 21:58:35 Move completed ...