Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] UUID's as primary keys

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Thomas Hallgren <thomas(at)tada(dot)se>, Greg Stark <gsstark(at)MIT(dot)EDU>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Psql_General <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] UUID's as primary keys
Date: 2006-06-29 15:54:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:

> On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
> > I have to concur with this. Assume you use a bytea for a UUID that in 
> > turn is used as a primary key. The extra overhead will be reflected in 
> > all indexes, all foreign keys, etc. In a normalized database some tables 
> > may consist of UUID columns only.
> So you create a UUID type. It's cheap enough to create new types after
> all, that's one of postgresql's strengths. What I'm saying is that it's
> easier to create new fixed length types for the cases that need it,
> than it is to redo the entire type handling of the backend.

I guess my motivation here is that I feel currently char(n) is basically
broken in Postgres. Sure it satisfies the letter of the specification, but
it's failing to actually achieve anything for the users. There's no point at
all in using char(n) in Postgres since it takes exactly the same amount of
space as varchar() if you're always stuffing it full and more space if you're

In the current setup the only reason for Postgres to have this data type at
all is purely for legacy compatibility. It doesn't actually "work" in that it
doesn't provide the space savings it's intended to and that would give users
an actual reason to use it in new databases.


In response to


pgsql-hackers by date

Next:From: Marc MunroDate: 2006-06-29 15:58:48
Subject: Re: Index corruption
Previous:From: Bruce MomjianDate: 2006-06-29 15:27:07
Subject: Re: vacuum, performance, and MVCC

pgsql-general by date

Next:From: Jasbinder BaliDate: 2006-06-29 16:08:44
Subject: Re: Database connectivity using a unix shell
Previous:From: Scott MarloweDate: 2006-06-29 15:33:13
Subject: Re: Database connectivity using a unix shell

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group