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

Re: [PERFORMANCE] Buying hardware

From: David Rees <drees76(at)gmail(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, A B <gentosaker(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORMANCE] Buying hardware
Date: 2009-01-26 19:42:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, Jan 26, 2009 at 4:09 AM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
> On Sun, 25 Jan 2009, Scott Marlowe wrote:
>> More cores is more important than faster but fewer
>> Again, more slower disks > fewer slower ones.
> Not necessarily. It depends what you are doing. If you're going to be
> running only one database connection at a time, doing really big complex
> queries, then having really fast CPUs and discs is better than having lots.
> However, that situation is rare.

If backup/restore times are important, having a fast CPU is important
because backup/restore is single threaded and unable to use more than
one CPU. OK, two CPUs, one for the pg_dump process and one for the
postgres daemon - but who buys anything with less than two cores these

We do daily backups of our databases, and although our biggest isn't
very large at approximately 15GB, backups take a bit more than an hour
with one CPU maxed out.  This system has two Xeon 5130 @ 2GHz, so even
with the fastest processors, we can only reduce backup times by at
most 50%.

During normal workloads, processing hundreds of queries a second,
system utilization stays below 10% on average - so for us, fewer cores
that are faster would be a better purchase than more cores that are

Lots of people have databases much, much, bigger - I'd hate to imagine
have to restore from backup from one of those monsters.


In response to


pgsql-performance by date

Next:From: JeffDate: 2009-01-26 19:58:05
Subject: Re: [PERFORMANCE] Buying hardware
Previous:From: Greg SmithDate: 2009-01-26 19:26:55
Subject: Re: postgresql 8.3 tps rate

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