> From now on I will therefore assume that compression is a very > good thing because it offers a win-win situation for large databases :-) I think you're right -- it might be worth instrumenting the kernel to note for the test process how many hits it got in the buffer cache for the two runs vs. how many times it had to do I/O. Or, maybe that information is already available? Regardless -- would you please characterize for me what the tests you're running do? (I know you're using dbbench, were there others?) What I'm trying to understand is what the data and data access patterns are for these tests. Thanks, --keith ------------------------------------ To unsubscribe from the htdig3-dev mailing list, send a message to [EMAIL PROTECTED] containing the single word "unsubscribe" in the SUBJECT of the message.
