And no, I don’t want to start a flame war, but this really doesn’t look like real database development to me. But this discussion is old, maybe I should read more what’s been done in the past 1,5 years. I won’t hold my breath, though.

Is implemented in mysql-server level, it’s internally referred to as BKA (batched key access)
It’s implemented for cluster (to reduce latency, instead of ordering reads)

I’m not sure exactly which mysql version this will appear in.
References:
http://forge.mysql.com/worklog/task.php?id=2771

Falcon is obviously derived from previous Jim’s work on Groton database (later it was known as Interbase, now as Firebird SQL server). Any one familiar to those db engines will recognise many features, described above, as well-known strong and poor points of Firebird SQL server.

For example, about transacttions above, preferred way to use Interbase/Firebird is a bi-transactional mode: one transaction is never-closing read-only read-commited one, another connection used to commit all the changes to database in a serie of short-lived not-read-only serializable transactions. Guess something alike will work fine for most application over Falcon engine.

BTW, one known drawback about Firebird/Interbase is its beeing ACID on row-level but being not on row-level. For example INSERT INTO TABLE SELECT * FROM TABLE would not duplicate a table, buit instead continue cloning itself until all possible disc space for database file would be claimed. I wonder if this is the same for Falcon SQL engine ? this is not obvious rooks on you step-way If found true, i think anyone experimenting with Falcon engine is better to keep an eye on Firebird/Interbase historic users experience, until with development going on codebases wold diverge that far that features and drawbacks of engines would became unrelated (will it? both engines are based partially on Jim’s idea of most practical database, hence with different code it perhaps would tend to achieve the same goals)

Right now you simply should not run MySQL with default settings - performance will be really poor.

Some auto configuration functions would be good but take out parameters would not be.

Would be interresting if some auto settings could be developed within mysql so we could get the best from each world… in other words allow both “read_buffer = 32M” aswell as “read_buffer = auto”.

Also the examples which is included mysql (my-huge.cnf etc) seems a bit outdated regarding how the memory is being used in today versions of mysql 5.x.

What you’re saying is “one option is best, if database can manage it optimally” I totally agree with you and I would enjoy having zero options and let database to read my mind what is really important for this application (as it is tradeof in many cases).

My main point is it is not possible or hard to get it right so have automatically detected defaults but still let users to adjust behavior if algorithm fails for some reason.

Compare it to MySQL Optimizer for example. It is designed to provide optimal query plan right ? But we all know it does not always do it and no optimizer gets it right in 100% cases - this is what hints are for.

Removing hints before optimizer is right in 100% cases would be silly, I feel same about configuration options.