Hi Jeff, I'ved tried this test using the -S flag './pgbench -c 4 -j 2 -T 600 -S pgbench'
Desktop gives me ./pgbench -c 4 -j 2 -T 600 -S pgbench starting vacuum...end. transaction type: SELECT only scaling factor: 1 query mode: simple number of clients: 4 number of threads: 2 duration: 600 s number of transactions actually processed: 35261835 tps = 58769.715695 (including connections establishing) tps = 58770.258977 (excluding connections establishing) Server ./pgbench -c 4 -j 2 -T 600 -S pgbench starting vacuum...end. transaction type: SELECT only scaling factor: 1 query mode: simple number of clients: 4 number of threads: 2 duration: 600 s number of transactions actually processed: 22642303 tps = 37737.157641 (including connections establishing) tps = 37738.167325 (excluding connections establishing) On 8 April 2013 21:39, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, Apr 8, 2013 at 12:31 PM, Mark Davidson <m...@4each.co.uk> wrote: > >> Thanks for your response Vasillis. I've run pgbench on both machines >> `./pgbench -c 10 -t 10000 pgbench` getting 99.800650 tps on my local >> machine and 23.825332 tps on the server so quite a significant difference. >> > > These results are almost certainly being driven by how fast your machines > can fsync the WAL data. The type of query you originally posted does not > care about that at all, so these results are not useful to you. You could > run the "pgbench -S", which is getting closer to the nature of the work > your original query does (but still not all that close). > > Cheers, > > Jeff >
