-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok sorry my mistake.
Doesn't however take away the *current* 8.2 documentation on using
INT4 versus INT8.
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).
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?
Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFGuGmv2M1B/aDfmXsRAjaTAKC5aXCuy8BUx0Tg4M9Q5zMpiskVDwCfVy+o
scumDxA1g+G8+8dG3rbrE6o=
=ezse
-----END PGP SIGNATURE-----
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
