Re: [GENERAL] UUID's as primary keys

From: Thomas Hallgren <thomas(at)tada(dot)se>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, 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 13:54:36
Message-ID: 44A3DB9C.8040205@tada.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Greg Stark wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>
>
>> To be honest, it seems like a lot of work to save the four bytes of
>> overhead for the varlena structure on disk if you're going to need it
>> in memory anyway. And anything like RAW(16) which people want for
>> UUIDs, if it's going to have a lot of functions associated with it, may
>> as well just be a new type.
>>
>
> For large databases storage density leads directly to speed. Saving four bytes
> of overhead on a 16-byte data structure would mean a 20% speed increase. Even
> if that's only helpful on a tenth of the columns you're still talking about a
> 2% speed increase for all queries on the table. A lot of databases use CHAR(1)
> for flags. The overhead is even worse there.
>
>
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.

Regards,
Thomas Hallgren

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-06-29 14:06:09 Re: pg_restore: [archiver] could not open input file
Previous Message Greg Stark 2006-06-29 13:47:01 Re: [GENERAL] UUID's as primary keys

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-29 14:10:54 Re: session id and global storage
Previous Message Rodrigo De Leon 2006-06-29 13:48:21 Re: session id and global storage