Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD
| От | Tom Lane |
|---|---|
| Тема | Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD |
| Дата | |
| Msg-id | 18193.1130786703@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD (Simon Riggs <simon@2ndquadrant.com>) |
| Список | pgsql-general |
Simon Riggs <simon@2ndquadrant.com> 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
В списке pgsql-general по дате отправления: