Re: UUID - Data type inefficient

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc>, "Kless" <jonas(dot)esp(at)googlemail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UUID - Data type inefficient
Date: 2008-07-10 16:56:15
Message-ID: 87iqvdd6fk.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Mark Mielke <mark(at)mark(dot)mielke(dot)cc> writes:
>> Kless wrote:
>>> [1] http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
>
>> That's a general page about UUID vs serial integers.
>
> AFAICT the author of that page thinks that UUIDs are stored in ASCII
> form (32 hex digits), which would indeed be inefficient.

Well he does say "In fact if you store UUID in binary form you can bring it
down to 16 bytes so size is not really the problem." Though I'm unclear why he
thinks a 4x increase in space usage is "not really a problem".

If you have a highly relational database you can easily have half or more your
columns in large tables consisting of foreign keys. If your database is i/o
bandwidth limited that would be a huge effect.

> I have no idea whether he knows what he's talking about with respect to
> mysql, but it's certainly 100% irrelevant to the Postgres datatype.

The rest of it seems to be pretty mysql-specific. Some of the problems are
universal such as making index inserts especially random and making clustering
impossible, but how much they hurt on different databases is going to be very
different.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2008-07-10 17:05:46 Re: Protocol 3, Execute, maxrows to return, impact?
Previous Message Kaare Rasmussen 2008-07-10 16:43:41 Re: UUID - Data type inefficient