Hi, I have been studying the basic limitation that the number of committed transactions per second possible in a relational databases is limited by the number of writed per second of the underlying hard disk, since each transaction requires at least the write-ahead log data
to be flushed to disk on commit, thus limiting the number of durable transactions commits possible per second. Its often possible to increase the total transaction processing speed by turning off the compulsory disc "syncing" at each commit, which means that in the case of system failure some transactions may be lost *but* the database would still be consistent if the log is always written first. I observed that in in many applications there are some transactions that are more "critical" than others. I may have the same database instance managing website visitor accounting and financial transactions. I could tolerate the loss of a few transactions whose only job is to tell me a user has clicked a page on my website but would not dare risk this for any "real" (e.g. financials) work my web-based app may be doing! In the case of bulk inserts, also, or in some such special cases the database user or administrator might be able to code around the need for guaranteed *durability* on transaction commit as long as the database is consistent. So I want to ask, what is RDBMS have a 'COMMIT NOSYNC;' option?" Then we can really improve "transaction-per-second" performance for a database that has lots of non-critical transactions while not jeopardising the durability of critical transactions in the (relatively improbable but quite possible) case of system failure, primarily through combining the log updates for several non-critical transactions. COMMIT [SYNC]; (guarantees atomic, consistent, durable transaction data write) COMMIT NOSYNC; --> (sacrifice durability of non-critical transaction for overall speed). So, the question is what people, especially those who have done RDBMS internals work, think about the implementation and the application of such options, especially in MySQL. Seun Osewa. SIZE does matter - The UK's biggest *Free* Web based mail - 10 MB Free mail.lycos.co.uk
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
