Skip site navigation (1) Skip section navigation (2)

Re: Processor speed relative to postgres transactions per second

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Chris Barnes <compuguruchrisbarnes(at)hotmail(dot)com>
Cc: Postgres General Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Processor speed relative to postgres transactions per second
Date: 2010-03-29 18:20:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Recently I ran a set of tests on two systems:  a 4-core server with 5 
disks (OS + WAL + 3 for DB) on a battery backed disk controller, and a 
newer Hyper-threaded design with 4 physical cores turning into 8 virtual 
ones--but only a single disk and no RAID controller, so I had to turn 
off its write cache to get reliable database operation.  (See )

When running pgbench with its simple built-in SELECT-only test, on a 
tiny data set that fits in RAM, I went from a peak of 28336 TPS on the 
4-core system to a peak of 58164 TPS on the 8-core one.

On the default write-heavy test, the 4-core server peaked at 4047 TPS.  
The 8-core one peaked at 94 TPS because that's as fast as its single 
disk could commit data.

The moral is that a faster processor or more cores only buys you 
additional speed if enough of your data fits in RAM that the processor 
speed is the bottleneck.  If you're waiting on disks, a faster processor 
will just spin without any work to do.  You can't answer "will I get 
more transactions per second?" without specifying what your transaction 
is, and knowing what the current limiter is.

Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support

In response to

pgsql-general by date

Next:From: Greg SmithDate: 2010-03-29 18:41:50
Subject: Re: playr (or similar tool)?
Previous:From: John GageDate: 2010-03-29 18:12:47
Subject: Re: How long will the query take

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group