Re: Benchmarking SQL drivers

New measurements after 2 fixes.
The PostgreSQL database had a slightly lower background load this time,
so I redid the two pgsql benchmarks every time.

The still remaining edge of the old pgsql driver over the new one
when using batches of one can be due to two things:
a. The old C-helper function for decoding the arguments of a row was somewhat
   more efficient than the current Pike only version.
b. The extra Mutexes needed to get Buffer output and input properly
   working with the nonblocking socket might add some latency.

However, it might not be worth the extra trouble because:
- I still beat the MySQL driver in the batches-of-1 case (ever so slightly).
- The difference with the old pgsql driver is perhaps sufficiently small.

This is 3940 queries running in batches of 1:
16.2s  pgsql    Pike 8.1 (new driver, multithreaded)
16.5s  MySQL    Pike 8.1
15.2s  pgsql    Pike 7.8 (old driver, single threaded)
21.3s  postgres Pike 8.1 (C-libpq)

This is 3940 queries running in batches of 2:
20.3s  pgsql    Pike 8.1 (new driver, multithreaded)
19.4s  MySQL    Pike 8.1
20.3s  pgsql    Pike 7.8 (old driver, single threaded)
34.8s  postgres Pike 8.1 (C-libpq)

This is 3940 queries running in batches of 5:
14.7s  pgsql    Pike 8.1 (new driver, multithreaded)
18.6s  MySQL    Pike 8.1
18.0s  pgsql    Pike 7.8 (old driver, single threaded)
31.1s  postgres Pike 8.1 (C-libpq)

This is 3940 queries running in batches of 10 (the initial benchmark):
10.9s  pgsql    Pike 8.1 (new driver, multithreaded)
17.3s  MySQL    Pike 8.1
17.6s  pgsql    Pike 7.8 (old driver, single threaded)
32.7s  postgres Pike 8.1 (C-libpq)

This is 3940 queries running in batches of 100:
 6.0s  pgsql    Pike 8.1 (new driver, multithreaded)
15.1s  MySQL    Pike 8.1
16.3s  pgsql    Pike 7.8 (old driver, single threaded)
29.2s  postgres Pike 8.1 (C-libpq)

-- 
Stephen.