Re: INDEX Performance Issue

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(dot)janes(at)gmail(dot)com> wrote:

> On Mon, Apr 8, 2013 at 12:31 PM, Mark Davidson <mark(at)4each(dot)co(dot)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
>