Baron, My naming policy is describe by the name of "component" and "method" to eliminate suspicious and subjective. Never by "effect", "purpose". I know the such kind of complain is often from less-understanding about InnoDB. I don't assume the less-understanding users. I think all users who want to use InnoDB effectively should understand InnoDB. As deeper understand, he should obtain better setting. The good example of past about it is about "adaptive_checkpoint". I named it as "adaptive_flush(ing)" at first I implemented. Because it controls the amount of flushing blocks by background thread to make small the impact and possibility that the checkpoint effect affects to performance. But, Peter and Vadim forced to change the name for "adaptive_checkpoint". I think it is name for the purpose. Bad name for describe the function. Though it was attractive and catchy, it was wrong and made misunderstanding. I think such wrong and misunderstanding should obstruct the next step to improve InnoDB more. I'd like to be sincere for all MySQL/InnoDB users. If don't understanding, please study. I believe "don't understanding" is much better than "misunderstand" for MySQL/InnoDB ecosystem. If the "don't understand" is from wrong expression of English language, I will try to fix. But from less understanding, I never accept it. That's why I need the your reason. The your reason should explain the what cause the "don't understand". >>> INNODB_AUTO_LRU_DUMP >>> to >>> innodb_enable_fast_warmup >> >> fast? warmup? >> I don't like to cheat users. It is really not concrete name. >> The name should express the effect cleanly. > > Users will not understand auto_lru_dump. The effect of the variable > is that the server becomes ready to answer queries more quickly after > starting. This is what users will understand and care about. > However, I think you are correct. There could be many different ways > to make the server warm up more quickly, and we should name them > specifically. I think that we might consider a name such as > "innodb_buffer_pool_save_restore". It is also a bad name, but > "buffer_pool" is much better than "lru" for users. (We should also > not use "dump" because it has a slightly different and unprofessional > meaning in English, and the behavior is not only to save the LRU, it > is also to restore it from the saved information.) The relation between method and effect should be studied. If you don't imagine the effect from the method name, I don't recommend not to use it, because you should mistake about using. The name should be sincere as I described above. And users should know the option cause the new file to be used by it. So the verb should be used to associate accessing another file. The method name candidates are "dump" (auto periodical) "save" (auto periodical) "preload_at_startup" "restore_at_startup" The component name candidates are "lru" "buffer_pool" "list of cached_data_pages" The exactly what is saved in the file is list of the pairs of space_id and page_no. So, "lru_list of buffer pool" is best component to be described. Only "buffer pool" may cause misunderstanding to store also the component of the pages like the double write buffer, so it seems worse for me. If "lru" is too short, "lru_list" is acceptable. If we assume really RDBMS amateur who don't know even "lru list", we don't use any name for all InnoDB options... >>> INNODB_EXPAND_IMPORT >>> to >>> innodb_enable_import_tables >> >> "IMPORT TABLE" is supported basically. It is wrong name. > > I agree. But I do not have a better suggestion. The current variable > name is very cryptic. It does not explain what the change in server > behavior is. Maybe we need a variable that explains "when importing a > tablespace, also do ________" ? What, exactly, does the variable > change? I think it renames the tablespace ID, right? I do not know > this feature's behavior very well. I understand... Hmm... In exactly, "allow different table space id and index id from another database" is effect. The component is "datafile to be imported" The method is "convert and align space id and trx id of the each records and so on." So.. "convert and align to the current database" is for your _____ place. innodb_auto_align(convert)_import_table ? >>> INNODB_OVERWRITE_RELAY_LOG_INFO >>> to >>> innodb_provide_replication_position >> >> I don't like to cheat users. It is really not concrete name. >> The name should express the effect cleanly. > > The behavior of the server is that after a crash, replication gets its > position information from the storage engine, not the relay log file. > The word "overwrite" sounds like something bad in English. It means > that some data is being destroyed. I propose > "innodb_recovery_update_relay_log". This does not seem perfect, but > it is better. Aha. "innodb_recovery_update_relay_log" is acceptable and sounds good for me too. > >>> INNODB_PASS_CORRUPT_TABLE >>> Rename to innodb_stop_on_corrupt_table=0|1 ( default is 1) >> >> The user should understand passing corrupt table is abnormal for RDBMS... >> It may not the problem only about the table. >> ,as I described before. >> >> InnoDB should abort for all corruption detections. >> >> You should explain the abnormal name for me, again. >> You didn't explain any at the previous report. >> I don't accept one-side intrusion... > > I do not propose to change the behavior. By default, InnoDB should > abort, as you say. But the word "pass" is very ambiguous in English, > and the meaning will not be clear to users. I propose > "innodb_abort_on_corrupt_table=0|1", with a default of 1. > I meant.. can we named using opposite and negative words like "force", "ignore" or something? (like same image for force_recovery. And it is more expandable in the future. e.g. add leveling) and default is 0 and 0 means abort when meet corruption.