On Mon, Mar 29, 2010 at 12:42 PM, Chris Barnes
wrote:
>
> We have two camps that think that the speed of cpu processors is/aren't
> relative to the number of transactions that postgres that can performed per
> second.
>
> I am of the opinion that is we throw the faster processors at the database
>
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 wri
On Mon, Mar 29, 2010 at 11:00 AM, Steve Atkins wrote:
> For larger databases, IO speed is the bottleneck more often than not. In
> those cases throwing memory, better disk controllers and faster / more drives
> at them will improve things. More CPU will not.
We're in the situation where we are
On Mar 29, 2010, at 9:42 AM, Chris Barnes wrote:
>
> We have two camps that think that the speed of cpu processors is/aren't
> relative to the number of transactions that postgres that can performed per
> second.
>
> I am of the opinion that is we throw the faster processors at the database
We have two camps that think that the speed of cpu processors is/aren't
relative to the number of transactions that postgres that can performed per
second.
I am of the opinion that is we throw the faster processors at the database
machine, there will be better performance.
Just like
