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
