Hi Jeff,
I'ved tried this test using the -S flag './pgbench -c 4 -j 2 -T 600 -S pgbench'./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)
./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.janes@xxxxxxxxx> wrote:
On Mon, Apr 8, 2013 at 12:31 PM, Mark Davidson <mark@xxxxxxxxxxx> 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
