On Mon, 2008-08-25 at 11:02 -0600, Scott Marlowe wrote:
> Well, of course a 64 bit int is gonna be bigger than a 32 bit, but
> with alignment issues and on 64 bit hardware, I'm guessing the
> difference isn't exactly twice as slow / twice as much storage. And
> it's way faster than a GUID which was what I think started this
> thread.
I took a slice of data from our dev box and generated a table using
integers and bigints. For reference, the schema is:
bigint table:
Type | Modifiers
--------+-----------
bigint |
date |
bigint |
bigint |
bigint |
bigint |
bigint |
date |
date |
bytea |
integer |
integer |
numeric |
numeric |
numeric |
integer |
integer |
integer |
integer |
integer |
integer |
integer |
bytea |
int table:
Type | Modifiers
--------+-----------
bigint |
date |
integer |
integer |
integer |
integer |
integer |
date |
date |
bytea |
integer |
integer |
numeric |
numeric |
numeric |
integer |
integer |
integer |
integer |
integer |
integer |
integer |
bytea |
The integer version is 599752704 bytes, and the bigint version is
673120256 bytes (a ~12% size increase). When joining the table to
itself (keys = 1 date, 5 (big)ints, no indexes), the bigint version
performs a join to itself with an average of 44.1 sec, and the integer
version in 29.6 sec (a 48% performance hit).
While granted that it's not twice as big and twice as slow, I think it's
a fairly valid reason to want to stay within (small)int ranges.
Sometimes the initial performance hit on insert would really be worth
the continuing space/performance savings down the road.
Of course, this wasn't very scientific and the benchmarks aren't very
thorough (for instance I assumed that bigserial is implemented as a
bigint), but it should remain a valid point.
Of course, it probably has no bearing on the OP's problem. So my advice
to the OP: have you considered not keying such a volatile table on a
serial value?
-Mark
