From: Greg Stark <gsstark@mit.edu>
To: mark@mark.mielke.cc
Cc: David Fetter <david@fetter.org>
Cc: nathan wagner <nw@hydaspes.if.org>
Cc: pgsql-hackers@postgresql.org
Subject: Re: uuid type for postgres
Date: 06 Sep 2005 19:34:30 -0400
Message-ID: <873bohwz21.fsf@stark.xeocode.com> (raw)
In-Reply-To: <20050906211624.GB3069@mark.mielke.cc>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: gsstark@mit.edu, mark@mark.mielke.cc, david@fetter.org, nw@hydaspes.if.org, pgsql-hackers@postgresql.org
Subject: Re: uuid type for postgres
In-Reply-To: <873bohwz21.fsf@stark.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox