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@mielke.cc>
