To: mark@mark.mielke.cc
Cc: David Fetter <david@fetter.org>,
	nathan wagner <nw@hydaspes.if.org>, pgsql-hackers@postgresql.org
Subject: Re: uuid type for postgres
References: <20050906135057.GA24136@granicus.if.org>
	<20050906144930.GA27641@mark.mielke.cc>
	<200509061002.43803.josh@agliodbs.com>
	<36e6829205090612575b954f38@mail.gmail.com>
	<20050906211613.GB26851@granicus.if.org>
	<20050906204928.GC24864@fetter.org>
	<20050906211624.GB3069@mark.mielke.cc>
In-Reply-To: <20050906211624.GB3069@mark.mielke.cc>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 06 Sep 2005 19:34:30 -0400
Message-ID: <873bohwz21.fsf@stark.xeocode.com>
Lines: 46
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


mark@mark.mielke.cc writes:

> Eventually, SERIAL wraps around. So you switch to SERIAL8. At the point that
> you have SERIAL8, you aren't worried terribly about disk space, and you
> realize there is usually no benefit at all to the numbers being ordered so
> closely.

a) Except for trivially small applications you are _always_ worried terribly
   about disk space. The more money you spend on high end raid arrays the
   *more* you're worried about an incremental drain on performance.

b) You only have to go to SERIAL8 for the few tables that actually have that
   many records. You may well still have SERIAL data types in 99% of your
   tables.

c) You underestimate the cost of the added space. Don't forget it's not just
   an extra few bytes in the primary key. It's also quadrupling the size of
   your primary key index (doubling over bigint).

   Most importantly it's also adding a few extra bytes to every foreign key
   column in every table that references that primary key. For very relational
   databases with tables doing things like many-to-many joins or having 4+
   foreign key referencing columns increasing all those integers to be 16
   bytes increases the size of your database *immensely*.

> Why not pick a scheme that is based on time? Perhaps create a revision code
> field to deal with objects created simultaneously from the same source. And
> why not identify the source to prevent collisions from multiple sources? If
> we go from 8 bytes, to 16 bytes, we can encode all of this information
> neatly. Welcome, UUID. :-)

Welcome to exactly the abuse that people are fearing if it were included as a
built-in type.

Personally I don't think the argument that some people might abuse it is a
good reason not to provide it. There are uses for which it's very effective --
even necessary. And I think it's important enough for the people that need it
that it should be considered a fundamental database feature these days. 

The people who will abuse it (like yourself, imho) will always exist and the
more powerful the tool the bigger the holes in their feet. Shouldn't stop us
from having powerful tools when we need them.

-- 
greg