No, you didn't read what I posted in reply to Mark originally.

myisam performance is not just down to the number of SELECTs you have, it's more complex than that and involves taking into account which of your queries will lock the entire table as they execute and which other queries may be running concurrently.

Any SELECTs involving joins, UPDATEs and INSERTs (in certain curcumstances) will cause the entire table to be write locked which may or may not be a problem depending on what else is going on at the same time.

For Marks tests, he seems to be doing quite intensive operations on a relatively large data set of 4.6m rows. I would hazard a guess that if he introduced some other query types on that data set to run concurrently (as one might get on a high transaction system) he would see some undesired locking situations.

MyISAM has a concurrent insert mode, which you can play with to allow it to append records to the end of the data file (rather than hunting for a gap in the middle of the data file) if there is another SELECT in progress, thus avoiding locking that SELECT out.

You can tailor it to your individual circumstances.

http://dev.mysql.com/doc/refman/5.1/en/concurrent-inserts.html

It's kinda like saying I couldn't care less, but in a more sarcastic way as Xen said. I guess it should be 'I could care less, but not without trying hard' or some such but, frankly, I could care less.

I have no idea whether it's American usage. It's not Swiss German, that's for sure.

I could care less.
(hippo)
I like it as it is. (Even thought I feel dirty that it might be merkan.)

You mean normalise, surely?

And, I don't get your point. Were you making a point?

I do mean normalise, yes. I was getting confused with summat I as reading on atomicity and transactions.

The point I was making was that many DBs will have SELECTs that include joins (including most of mine), so the MyISAM's weakness in SELECTs with joins is hardly trivial. OTOH, if it really only affects large tables ... how large is 'large'?

I've ended up using SimpleDB, which has no concept of joins but permits multiple values for attributes. So instead of 4 million rows, I've got 100,000 rows with around 40 values on each. Doing the same search takes a tenth of a second, plus, I get more information back and my algorithm is much more accurate.

Just registered a cool domain name, going to have a prototype within a week and beta by Xmas.

Edit: makes that a million records with 200 values on each. Doesn't seem to make any difference to response time.