*** 77,82 **** --- 77,91 ---- tens of connections both reading and writing data in multiple transactions simultaneously. Expand that to hundreds or thousands of connections on more hefty hardware. + *Reply*: As for ANALYZE, I'll see what I can do to add it to test script after + significant table changes. That should be OK I guess. I plan to include the + time cost of ANALYZE as part of those tests for Postgress. I consider this to be + fair since no other db gets any special treatment like this and AFAICT ANALYZE + is very fast.{linebreak} + No doubt, Postgres would shine in high concurrency tests but you're unlikely to + be interested in SQLite if you need hundreds of simultaneous writers/readers. + So, for now, I have no intention of running such tests. + Few notes about the results: *: Time is mesured in seconds, it represents wallclock time. *: nosync in case of SQLite means that SQLite is running with PRAGMA synchronous=OFF;. In case of *************** *** 102,107 **** --- 111,122 ---- might be to re-run the Postgres tests with 'explain analyze' for each query and provide that output as well to verify the query plan being used. + *Reply*: nosync tests were run simply to give better insight to SQLite + developers and users. MySQL was thrown into the mix there because, AFAIK, its + very common setup for MySQL to be run like that. Other then that, I'm mostly + interested in sync performance since that's the most common mode of operation. + Except maybe for MySQL, I'm not sure if this changed in last 3 years or so.{linebreak} + On to the tests now. *************** *** 255,260 **** --- 270,279 ---- <tr><td>MySQL 5.0.18 (nosync):</td><td align="right"> 3.725</td></tr> <tr><td>FirebirdSQL 1.5.2:</td><td align="right"> 5.187</td></tr> </table> + * Performance of PostgreSQL in this test is most probably heavily impacted by + <i>psql</i> command line utility. Same test when run form pgAdmin III GUI completed + in 5 seconds. + <h2>Test 9: 1000 UPDATEs without an index</h2> <blockquote> BEGIN;<br>