| From: | tsuraan <tsuraan(at)gmail(dot)com> |
|---|---|
| To: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | UUID as primary key |
| Date: | 2009-10-09 16:56:24 |
| Message-ID: | 84fb38e30910090956q1dc93945q488f5cf704931303@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
I have a system where it would be very useful for the primary keys for
a few tables to be UUIDs (actually MD5s of files, but UUID seems to be
the best 128-bit type available). What is the expected performance of
using a UUID as a primary key which will have numerous foreign
references to it, versus using a 64-bit int (32-bit isn't big enough)?
From the uuid.c in adt, it looks like a UUID is just stored as 8
consecutive bytes, and are compared using memcmp, whereas an int uses
primitive CPU instructions for comparison. Is that a significant
issue with foreign key performance, or is it mostly just the size that
the key would take in all related tables?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Otis | 2009-10-09 17:46:49 | Databases vs Schemas |
| Previous Message | Alan McKay | 2009-10-09 16:45:14 | disk I/O problems and Solutions |