Re: UUID - Data type inefficient

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: UUID - Data type inefficient
Дата
Msg-id 87iqvdd6fk.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: UUID - Data type inefficient  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Mark Mielke <mark@mark.mielke.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!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kaare Rasmussen
Дата:
Сообщение: Re: UUID - Data type inefficient
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: Protocol 3, Execute, maxrows to return, impact?