-----BEGIN PGP SIGNED MESSAGE-----
to keep you up to date:
we tested with a simple dd-read on different machines and mount-points:
400MB file (created with "dd if=/dev/urandom of=file100Mb bs=512
count=800000" on the intel-linux-box):
reading the file with dd to /dev/null on
a) the sparc-solaris:
veritas-disk: 24sec (over fiber on symmetrix)
b) the intel-linux
the intel-box does have some pretty modern scsi-disks in a raid-5.
the intention was to get a feeling how much the hd's will be a part of
the problem. we didn't want to get some absolute benchmarks :-))
so it points to the disks.
but now somethin really cool:
we took a closer look on our table and tried to figure out why the
disks are so important for our select. if you remember: it was a
varchar-field that took us some time. the intersection of this
varchar-field an an integer-field was one of the major results we
both field for themselfs had around 400.000 rows in the result-set. the
intersection (WHERE myvarchar="mac" AND myint=1) only gives 130 to 500
so we finally did something we should have done long before :-(
we changed the varchar into a int (creating an extra table for
translation) and created a combined index over both fields. the first
step brought us 5 to 8 secs speedup and the combined index just got us
crazy. it now takes 0.01secs.....
so for one specific statement the combination of better to index types
and combined index with better cardinality helps a lot.
but there is still the dependency to the disks.
if the intersection of both int-fields wouldn't be such a small result,
i am pretty sure the speed would be as bad as before.
we will work on it a little bit further.
but if you have some comments on that: please help us :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----