Hi,
At first thanks for the answer. I was wondering if my mail was precise enough. > Your results could have a lot to do with the fact that HEAP tables > used hashed indexes rather than the B-Tree indexes of MyISAM. The set No, I've really used queries that take advantage of the hash indexes : i.e. only full keys (not partial), and equality tests (not range or inequality). I've checked it by asking EXPLAIN SELECT : the indexes are used. The first tests were done with partial keys and results were really worse, by the way, but I figured this out and corrected it. Also, the queries are very simple so there is no chance that queries on MyISAM use a bigger amount of indexed columns than on HEAP. It really seems to me that SELECTs should be faster than INSERTs because everything the SELECT does (finding the right leaf in the index tree / hash), the INSERT also does, and the latter furthermore allocated and appends data. I have come to think that the overhead could come from parsing the request and optimizing it, or maybe sending the data to the client (by the way, it is connected via a Unix socket - networking is disabled in the my.cnf) ? (the test does 5000 simple SELECTs and it lasts for 2 or 3 seconds, whereas for 10000 simple INSERTs it only lasts for a fraction of second - all this on HEAP tables). >>This was done with MySQL 3.23.43 source distribution, on a >>bi-processor Intel Redhat box. >> > > Which kernel version? Did the machine swap during your tests? 2.4.16, the filesystem is ext3 with noatime. The machine didn't seem to swap (top showed no change in the amount of allocated memory). Yours Antoine. --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
