Hey Jamie, thank you very much for the patch, it makes sense to me. And i've just committed it in mainstream code. However, taking apart the concurrent access, do we have a way to measure the speed of things ? I suspect EXPLAIN is not our friend here (ie. to measure speed of transactions rather than of single stataments).
I'm asking because i've been unable to find a reasonable answer for PostgreSQL; while, in fact, MySQL documentation has nice "Speed of ..." sections, PostgreSQL seems to lack of them. In particular, about the speed of INSERTs & LOCKs, MySQL documentation ( http://dev.mysql.com/doc/refman/5.0/en/insert-speed.html ) says: === To speed up INSERT operations that are performed with multiple statements, lock your tables. ... This benefits performance because the index buffer is flushed to disk only once, after all INSERT statements have completed. Normally, there would be as many index buffer flushes as there are INSERT statements. Explicit locking statements are not needed if you can insert all rows with a single INSERT. ... For transactional tables, you should use START TRANSACTION and COMMIT instead of LOCK TABLES to obtain faster insertions. Locking also lowers the total time for multiple-connection tests, although the maximum wait time for individual connections might go up because they wait for locks. For example: 1. Connection 1 does 1000 inserts 2. Connections 2, 3, and 4 do 1 insert 3. Connection 5 does 1000 inserts If you do not use locking, connections 2, 3, and 4 finish before 1 and 5. If you use locking, connections 2, 3, and 4 probably do not finish before 1 or 5, but the total time should be about 40% faster. === The second part of the above reasoning, should confirm that (while dealing with transactions - ie. precisely what happens only in the PostgreSQL plugin) the patch is going greatly the right way. Though, some argumentations are still vague and, in the end, we could be able to get an answer just measuring things. Thoughts ? Cheers, Paolo
