Re: Migrate postgres to newer hardware

From: Rosser Schwarz <rosser(dot)schwarz(at)gmail(dot)com>
To: Renato Oliveira <renato(dot)oliveira(at)grant(dot)co(dot)uk>
Cc: Tino Schwarze <postgresql(at)tisc(dot)de>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Migrate postgres to newer hardware
Date: 2010-03-30 15:23:49
Message-ID: 37d451f71003300823n2b9e3707n16676c41cb8883a9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Mar 30, 2010 at 8:51 AM, Renato Oliveira
<renato(dot)oliveira(at)grant(dot)co(dot)uk> wrote:
> If I use postgres 32 bit will it benefit from the extra memory on the system?

Indirectly, yes. No individual PG process will be able to address
more than 4 gbytes of memory. Assuming you have a 64-bit OS living
underneath, however, that may not matter much. You'll potentially be
somewhat constrained in the sane values you can use for shared_buffers
(which, on a 16 gbyte box for example, I'd probably start in the 4
gbyte range and tune from there -- not an option in a 32-bit install).

But leaving aside effective_cache_size (and, as mentioned, potentially
shared_buffers), none of your config values are likely to approach the
4 gbyte boundary -- and in the case of effective_cache_size, that
isn't actually directly addressed by postgres, anyway. It's just used
by the planner to calculate the likelihood of a given page it needs
being in the OS buffer cache, instead of on disk.

I've had production systems with a 32-bit postgres running quite
happily on a 64-bit OS.

rls

--
:wq

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Iñigo Martinez Lasala 2010-03-30 15:26:35 Re: Migrate postgres to newer hardware
Previous Message Tom Lane 2010-03-30 15:15:52 Re: Migrate postgres to newer hardware