From: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
---|---|
To: | Kless <jonas(dot)esp(at)googlemail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UUID - Data type inefficient |
Date: | 2008-07-10 15:52:57 |
Message-ID: | 48763059.8030709@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kless wrote:
> The new data type, UUID, is stored as a string -char(16)-:
>
> ------------
> struct pg_uuid_t
> {
> unsigned char data[UUID_LEN];
> };
> #define UUID_LEN 16
> ------------
>
> but this it's very inefficient as you can read here [1].
>
> The ideal would be use bit(128), but today isn't possible. One
> possible solution would be create a structure with 2 fields, each one
> with bit(64).
>
>
> [1] http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
>
>
That's a general page about UUID vs serial integers.
What is the complaint? Do you have evidence that it would be noticeably
faster as two 64-bits? Note that a UUID is broken into several non-64
bit elements, and managing it as bytes or 64-bit integers, or as a union
with the bit-lengths specified, are probably all efficient or
inefficient depending on the operation being performed. The hope should
be that the optimizer will generate similar best code for each.
Cheers,
mark
--
Mark Mielke <mark(at)mielke(dot)cc>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-10 16:00:43 | Re: UUID - Data type inefficient |
Previous Message | David Fetter | 2008-07-10 15:34:33 | Re: WITH RECURSIVE updated to CVS TIP |