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
|
| Список | 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 wouldallow the 18446744073709551615 (is that the max value?) max valueavailable in mysql. Or am I missing something?You'd have to translate that to NUMERIC, which would work but wouldtake 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 по дате отправления: