I don't recommend it. There are better ways to store UUIDs:
char(32) <-- Easy to work with, fixed length, inefficient
varchar(32) <-- 4 bytes larger due to variable size
bytea() <-- 20 bytes, variable length
bit(128) <-- 16 bytes, optimal
I don't like char() or varchar() because of case-senstivity and
inefficiency.
We used bytea, and created a small function byte2guid() and guid2byte()
to handle converting to/from strings when working at a SQL prompt. But
the production code doesn't use those. In retrospect, I would like to
have tried BIT(128) since I think fixed-length columns perform better
than variable-length columns.
Matthew Hixson wrote:
> I'm investigating the usage of a UUID primary key generator using
> Hibernate and Postgres. The reason for using a UUID is that we will
> have an application hosted at different sites in different databases.
> We will need to aggregate the data back into a single database from time
> to time and we want to avoid PK collisions.
> Is there a significant performance difference between using int
> primary keys and string primary keys in Postgres?
> Thanks,
> -M@
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
