Re: TODO item: GUID - Mailing list pgsql-hackers

From mark@mark.mielke.cc
Subject Re: TODO item: GUID
Date
Msg-id 20060909220316.GA32672@mark.mielke.cc
Whole thread Raw
In response to Re: TODO item: GUID  ("Aleksandar Dezelin" <dezelin@gmail.com>)
Responses Re: TODO item: GUID  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: TODO item: GUID  (Thomas Hallgren <thomas@tada.se>)
List 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@mielke.cc / markm@ncf.ca / markm@nortel.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
bindthem...
 
                          http://mark.mielke.cc/



pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Move completed ...
Next
From: "Lamar Owen"
Date:
Subject: Re: [Pgsqlrpms-hackers] Safer auto-initdb for RPM init