Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vlad <marchenko(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD
Date: 2005-10-31 21:44:33
Message-ID: 1130795073.8300.1525.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2005-10-31 at 14:50 -0600, Scott Marlowe wrote:

> As I understand it, when the last backend referencing a collection of
> data stops referencing it, that the buffers holding that data are
> released, and if, a second later, another backend wants the data, then
> it has to go to the Kernel for it again.

Unreferenced data is not immediately released to the kernel. When a
backend requests a datablock that is not in shared_buffers it will
select an unreferenced buffer, write it if required (hopefully not
required because of the bgwriter), then overwrite the shared_buffer
cache with the datablock it is trying to read from "disk". All reads and
writes go through the OS cache, which does pretty much the same thing
but with a different algorithm. So "disk" might just mean OS cache.

There's zero *requirement* for the OS cache to be bigger than
shared_buffers. Martijn and Tom discuss that there are a number of
advantages to not overallocating shared_buffers, which is the reason why
the usual recommendation is to not do that.

Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-10-31 21:47:50 Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD
Previous Message Alex Turner 2005-10-31 21:39:18 Re: SQL injection