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

From Gregory Youngblood
Subject Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type
Date
Msg-id A0715BCA-96F8-401C-B1C6-DEB9E952690D@netio.org
Whole thread Raw
In response to Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [pgsql-advocacy] MySQL to PostgreSQL, was ENUM type
Next
From: Tom Lane
Date:
Subject: Re: Upgrading from 7.1