Hi Monty,

The problem is that a too simple my.cnf will please very few (mainly desktop users) and leave the a bit more advanced user to search on the net and get 'anything' that looks remotely right.

I respectfully disagree. I think the sample my.cnf is targeted for desktop users, medium-sized company users, and small business owners whose expertise is low and frustration level can run high. A generic, simple, and short my.cnf file serves that constituents well, gains their confidence, and is conducive in building up their comfort and skill level gradually, that they would seek information themselves on the web and/or ask expert for help as the need for performance/scalability rises. But that is AFTER they are comfortable enough with the ease, power, and simplicity of MariaDB. In other words, my view is that its target audience is not big size social network sites, Facebook, Google, and other money-rich financial companies. Those guys probably don't need the built-in sample anyway. Personally, I feel a minimalistic file works the best. This is not a debate of enterprise-worthiness of MariaDB/Percona/MySQL. It is. It's just that I think the sample's target is small scale users, relatively speaking.

I prefer the other approach taken by most unix programs (like postfix) have taken where you have most important options in the config file, but the not common ones are commented, with a good explanation of when to enable the option. This is makes it much faster to get good options without having to go trough a lot of manuals and web sites...

This will make it long, which tends to cause confusion. A typical user/developer will be overwhelmed by the slew of jargons, which is a turn-off, IMHO. Given the importance of key_buffer_cache, however, perhaps that should be mentioned as a comment.

I also personally like the original approach with small, medium, large and huge default config files, but now with many storage engines these are also not as valid as they originally where. (And I agree with Arjen that many of the values needs to be updates).

I actually went ahead with that assumption as well initially, but after some thinking, I feel that contradict with the simplicity rule, so I stopped. But the idea is still good, in my mind. So perhaps we can put my-1gb.cnf, my-4gb.cnf, my-32gb.cnf on the knowledgebase?

What should (at least) be done is to create new sections to the my.cnf files that one can easily enable if one uses different storage engines. I would also like to see more options and better comments in the defaults file.

I agree, but I think we should NOT put in samples for every storage engine under the sun. Once again, simplicity rules in my mind, so we need only cover 2: MyISAM (Aria when Aria is mature enough to phase out MyISAM) and InnoDB. I do realize that in the sample I sent out, I didn't put any for InnoDB, which is probably not a good idea.

I have this week actually added to MariaDB 5.2 some new startup options and groups to be able to make the option files smaller.

For example, now in 5.2 both the server and clients are reading the 'client-server' group, so one doesn't have to specify the socket and port twice.

I also added and --log-basedir so that one can specify the name for all log files with one command (instead of having to use 8+ different options) and new groups [mariadb] and [client-mariadb] so that one can use the same config file for MySQL and MariaDB running on the same computer.

That's fantastic! In summary, it appears that we disagree quite a bit on this. And the main point of contention, I think, is who is the target audience. There is definitely a need to replace/update the current ones, though. What about we package a minimalist sample my.cnf, and put a line in it pointing to a web page on KnowledgeBase that has more samples available with better explanation. Better yet, it is a wiki so the knowledge can be crowd-sourced. Haidong