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