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: | 72dbd3150901261142j76b29b0amccdf7a14b7aabfaa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2009-01-26 19:58:05 | Re: [PERFORMANCE] Buying hardware |
Previous Message | Greg Smith | 2009-01-26 19:26:55 | Re: postgresql 8.3 tps rate |