Re: [PERFORMANCE] Buying hardware - Mailing list pgsql-performance

From David Rees
Subject Re: [PERFORMANCE] Buying hardware
Date
Msg-id 72dbd3150901261142j76b29b0amccdf7a14b7aabfaa@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORMANCE] Buying hardware  (Matthew Wakeling <matthew@flymine.org>)
Responses Re: [PERFORMANCE] Buying hardware  (Jeff <threshar@torgo.978.org>)
List pgsql-performance
On Mon, Jan 26, 2009 at 4:09 AM, Matthew Wakeling <matthew@flymine.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
days?

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
slower.

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

-Dave

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: postgresql 8.3 tps rate
Next
From: Jeff
Date:
Subject: Re: [PERFORMANCE] Buying hardware