Re: Drawbacks of using BYTEA for PK?

From: Richard Huxton <dev(at)archonet(dot)com>
To: "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com>, David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Drawbacks of using BYTEA for PK?
Date: 2004-01-12 10:04:04
Message-ID: 200401121004.04173.dev@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sunday 11 January 2004 22:05, D. Dante Lorenso wrote:
> David Garamond wrote:
> > Are there any drawbacks of using BYTEA for PK compared to using a
> > primitive/atomic data types like INT/SERIAL? (like significant
> > performance hit, peculiar FK behaviour, etc).
> >
> > I plan to use BYTEA for GUID (of course, temporarily I hope, until
> > PostgreSQL officially supports GUID data type), since it seems to be
> > the most convenient+compact compared to other data types currently
> > available. I use GUIDs for most PK columns.
>
> GUID? Isn't that really nothing more than an MD5 on a sequence?
>
> SELECT (MD5(NEXTVAL('my_table_seq'))) AS my_guid;

I think the point of a GUID is it's supposed to be unique across any number of
machines without requiring those machines to coordinate their use of GUID
values.

I think the typical approach is to use something like:
hash_fn( network_mac_address || other_hopefully_unique_constant ||
sequence_val )
and make sure that the probability of getting collisions is acceptably low.

ISTR a long discussion a year or two back on one of the lists, for those that
are interested.
--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2004-01-12 10:12:07 Re: insertion with trigger failed unexpectedly
Previous Message Richard Huxton 2004-01-12 09:57:32 Re: Case sensitivity