Re: New server to improve performance on our large and busy DB - advice? (v2) - Mailing list pgsql-performance

From Craig Ringer
Subject Re: New server to improve performance on our large and busy DB - advice? (v2)
Date
Msg-id 4B4FBAD1.4040304@postnewspapers.com.au
Whole thread Raw
In response to Re: New server to improve performance on our large and busy DB - advice? (v2)  (Dave Crooke <dcrooke@gmail.com>)
Responses Re: New server to improve performance on our large and busy DB - advice? (v2)
List pgsql-performance
On 15/01/2010 6:35 AM, Dave Crooke wrote:
> I'll bite ....
>
>
> 1. In general, RAID-10 is the only suitable RAID configuration for a
> database. The decision making comes in how many drives, and splitting
> stuff up into LUNs (like putting pg_xlog on its own LUN).
>
>

> The biggest problem with Postgres on Windows is that it only comes in
> 32-bit. RAM is the ultimate performance tweak for an RDBMS, and to make
> proper use of modern amounts of RAM, you need a 64-bit executable.

.... though that's much less important for Pg than for most other
things, as Pg uses a one-process-per-connection model and lets the OS
handle much of the caching. So long as the OS can use all that RAM for
caching, Pg will benefit, and it's unlikely you need >2GB for any given
client connection or for the postmaster.

It's nice to have the flexibility to push up shared_buffers, and it'd be
good to avoid any overheads in running 32-bit code on win64. However,
it's not that unreasonable to run a 32-bit Pg on a 64-bit OS and expect
good performance.

You can always go 64-bit once 8.5/9.0 hits and has stabilized, anyway.

--
Craig Ringer

pgsql-performance by date:

Previous
From: Pierre Frédéric Caillaud
Date:
Subject: Re: Inserting 8MB bytea: just 25% of disk perf used?
Next
From: Greg Smith
Date:
Subject: Re: New server to improve performance on our large and busy DB - advice?