erix, I can't thank you enough for do that.

1. Ouch! I swear I had it in there at one point, but looking back to where this code originated, it was missing or in the wrong place back then.

   Position and frequency of commits is one of the many variables I've been playing with trying to get a handle on how they affect the overall performance. For example, if you uncomment the line:

   #        $n % 10 or $dbh->commit
   [download]

   The insertion takes 4 times as long.

2. $N is a command line parameter.

   My typical test runs consist of the command: for /L %t in (1,1,4) do @1045292 -N=1e6 -T=%t -Q=100 which is probably self explanatory.

From around N$ = 10_000 and upwards, the threaded version *is* (much) faster.

Weird thing is, varying the number of threads (-T=n) makes no difference to the time required to process all the records:

C:\test>1049236 -N=1e6 -T=1 -Qsize=1000
Took 86.039947 seconds (for Populate DB with 1e6 records)
Took 2.232394 seconds (for Create primary index)
Took 16.897088 seconds (for Retrieve the whole lot)
1000000
Took 0.268509 seconds (for Read all 1e6 records using 1 threads)

C:\test>1049236 -N=1e6 -T=4 -Qsize=1000
Took 85.957917 seconds (for Populate DB with 1e6 records)
Took 3.164024 seconds (for Create primary index)
Took 16.881054 seconds (for Retrieve the whole lot)
1000000
Took 0.251258 seconds (for Read all 1e6 records using 4 threads)
[download]

Leastwise, not when reading the records for the second time. Comment out the "Retrieve the whole lot" block and then things get muddy again:

C:\test>1049236 -N=1e6 -T=1 -Qsize=1000
Took 86.307525 seconds (for Populate DB with 1e6 records)
Took 2.363253 seconds (for Create primary index)
1000000
Took 0.978504 seconds (for Read all 1e6 records using 1 threads)

C:\test>1049236 -N=1e6 -T=4 -Qsize=1000
Took 86.182529 seconds (for Populate DB with 1e6 records)
Took 3.017540 seconds (for Create primary index)
1000000
Took 1.925757 seconds (for Read all 1e6 records using 4 threads)
[download]

Once the single-threaded, first pass through the data is removed, it takes twice as long for 4 threads to read all the records as it does for 1 thread.

But then, why does it take the single-threaded, read-all 16 seconds to do so; when it only takes 1 second to start an entirely new thread, make a completely new connection, and then read-all the records?

Many questions and little consistency from which to derive answers at this point. If you can see any other obvious cock-ups I'd be grateful to hear of them.

(Ps. Any feel for how Pg would compare in similar a application?)