Simon Riggs <simon@xxxxxxxxxxxxxxx> 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
