Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type

Поиск
Список
Период
Сортировка
От Gregory Youngblood
Тема Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type
Дата
Msg-id A0715BCA-96F8-401C-B1C6-DEB9E952690D@netio.org
обсуждение исходный текст
Ответ на Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general

On Jul 27, 2005, at 9:53 PM, Tom Lane wrote:

Gregory Youngblood <pgcluster@netio.org> writes:

... the problem is unsigned bigint in mysql to postgresql.  
There's not another larger integer size that can be used that would  
allow the 18446744073709551615 (is that the max value?) max value  
available in mysql. Or am I missing something?


You'd have to translate that to NUMERIC, which would work but would
take a bit of a performance hit ...

The most common places I've seen unsigned bigint used have been primary keys for tables where the counter is expected to basically grow forever. I've also seen it used to store unique user id numbers instead of varchar fields. In both of those cases, the number is used as a key, either alone or with another field, in an index. Would there be much of a performance hit for that type of use? I can image the biggest performance hit being mathematical calculations, such as sum(), etc. Or would the performance hit be across the board?

Greg

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Upgrading from 7.1