On Tue, Aug 07, 2007 at 02:46:39PM +0200, Marc Dirix wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > The problem is not as much in using INT8 agains INT4 als normal > column, where it brings virtually no penalty, however > in places where INT8 is used for an index it does. > > Bluntly speaking, if I change my indexed column from INT8 to INT4, > the index file will also shrink to half the size. Making the > lookup *less* IO bound. Also the hash for the index will be faster > (on 32bit machines).
Actually, pretty much anything on a 32 bit machine is going to be faster with an int4 than an int8. But you've also touched on the real meat of the issue... the penalty for int8 over int4 depends on context. The per-row overhead in 8.2 is normally 24 bytes by itself, so an extra 4 bytes isn't so noticeable until you get into 100M rows or so. But for a btree, I believe the overhead is only 6 bytes (which will normally become 8 bytes due to alignment), so an extra 4 bytes makes a huge difference. > A way to look at it, is to say just throw more RAID or 64bit cores at > it, but IMHO the software also has > to try and make it more optimized. Especially if also smaller user > setups are targeted. > > As to changing code, I've had a quick look at it (nothing more) but > is there really more to be changed then just the table specs? Generally, it's just a matter of changing the table definition and that's it. To make life easier you might want to use a domain so you only have to change in one place. But depending on your connection library, you might have to make some client-side changes as well. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828
pgpGgnxKTl6zO.pgp
Description: PGP signature
_______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
