Re: Benchmarking SQL drivers

The driver turns out to have some peculiar properties under load:

This is 3940 queries running in batches of 1:
19.4s  pgsql    Pike 8.1 (new driver, multithreaded)
16.5s  MySQL    Pike 8.1
15.6s  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:
23.5s  pgsql    Pike 8.1 (new driver, multithreaded)
19.4s  MySQL    Pike 8.1
21.4s  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:
15.6s  pgsql    Pike 8.1 (new driver, multithreaded)
18.6s  MySQL    Pike 8.1
18.6s  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):
11.3s  pgsql    Pike 8.1 (new driver, multithreaded)
17.3s  MySQL    Pike 8.1
18.4s  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.1s  pgsql    Pike 8.1 (new driver, multithreaded)
15.1s  MySQL    Pike 8.1
16.8s  pgsql    Pike 7.8 (old driver, single threaded)
29.2s  postgres Pike 8.1 (C-libpq)

Which shows that:
- The still is room for improvement in batches <5, where I'm beaten
  by my old singlethreaded driver.  That should not have been possible,
  so I'm going to compare network dumps there.
- Amazingly the new driver gets spectacularly faster at larger batch sizes.
  I'd guess that due to larger batch sizes, more network traffic
  is being coalesced to utilise full packets.
-- 
Stephen.