On Tue, Jan 27, 2015 at 4:46 PM, Stephen Frost <sfr...@snowman.net> wrote: >> With 0 workers, first run took 883465.352 ms, and second run took 295050.106 >> ms. >> With 8 workers, first run took 340302.250 ms, and second run took 307767.758 >> ms. >> >> This is a confusing result, because you expect parallelism to help >> more when the relation is partly cached, and make little or no >> difference when it isn't cached. But that's not what happened. > > These numbers seem to indicate that the oddball is the single-threaded > uncached run. If I followed correctly, the uncached 'dd' took 321s, > which is relatively close to the uncached-lots-of-workers and the two > cached runs. What in the world is the uncached single-thread case doing > that it takes an extra 543s, or over twice as long? It's clearly not > disk i/o which is causing the slowdown, based on your dd tests.
Yeah, I'm wondering if the disk just froze up on that run for a long while, which has been known to occasionally happen on this machine, because I can't reproduce that crappy number. I did the 0-worker test a few more times, with the block-by-block method, dropping the caches and restarting PostgreSQL each time, and got: 322222.968 ms 322873.325 ms 322967.722 ms 321759.273 ms After that last run, I ran it a few more times without restarting PostgreSQL or dropping the caches, and got: 257629.348 ms 289668.976 ms 290342.970 ms 258035.226 ms 284237.729 ms Then I redid the 8-client test. Cold cache, I got 337312.554 ms. On the rerun, 323423.813 ms. Third run, 324940.785. There is more variability than I would like here. Clearly, it goes a bit faster when the cache is warm, but that's about all I can say with any confidence. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers