Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2005-10-31 at 09:35 -0500, Tom Lane wrote:
>> The real point is that RAM dedicated to shared buffers can't be used for
>> anything else [1], whereas letting the kernel manage it gives you some
>> flexibility (for instance, to deal with transient large memory demands
>> by individual backends, or from stuff unrelated to Postgres).
> Agreed. But that is an argument in favour of more easily controllable
> server memory management, not a definitive argument against setting
> shared_ buffers higher.
Well, as long as shared_buffers is a fixed parameter, it's an argument
against setting shared_buffers higher ;-). But the larger point here
is that Postgres does not have the knowledge needed to make the same
kinds of memory tradeoffs that the kernel does. I think trying to usurp
this kernel functionality would be exactly the wrong design direction
for us to take.
>> [1] unless you are on a platform where the kernel doesn't think SysV
>> shared memory should be locked in RAM.
> This is a disaster for any database, not just PostgreSQL. But most other
> DBMS do something about this, for example on Linux, Solaris, HP/UX, AIX
> a certain orange DBMS provides additional support for making shared
> memory non-swappable.
Yeah, and we should do that too on platforms where it can be done
reasonably (ie, without root privs).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
