> > no table was ever large enough that 256k buffers would ever be filled by
> > the process of vacuuming a single table.
>
> Not 256K buffers--256K, 32 buffers.
Ok.
> > In addition, when I say "constantly" above I mean that the count
> > increases even between successive SELECT:s (of the stat
On Thu, 6 Nov 2008, Peter Schuller wrote:
In order to keep it from using up the whole cache with maintenance
overhead, vacuum allocates a 256K ring of buffers and use re-uses ones
from there whenever possible.
no table was ever large enough that 256k buffers would ever be filled by
the proces
Hello,
> At one point I envisioned making it smart enough to try and handle the
> scenario you describe--on an idle system, you may very well want to write
> out dirty and recently accessed buffers if there's nothing else going on.
> But such behavior is counter-productive on a busy system, whi
On Wed, 5 Nov 2008, Peter Schuller wrote:
In addition, PostgreSQL is not even close to even filling it's buffer
cache. The buffer cache is configured at 1 GB, and the resident size
of the PostgreSQL process is only 80-90 MB so far. So even
independently of any lru multplier setting, delays and w
