Re: DB cache size strategies - Mailing list pgsql-general

From Ed L.
Subject Re: DB cache size strategies
Date
Msg-id 200401301519.56488.pgsql@bluepolka.net
Whole thread Raw
In response to DB cache size strategies  ("Ed L." <pgsql@bluepolka.net>)
Responses Re: DB cache size strategies  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general
On Friday January 30 2004 2:33, Ed L. wrote:
>
> One key aspect of pgsql performance tuning is to adjust the memory
> consumption settings (shared_buffers, sort_mem, etc) large enough to hold
> as much of the database in shared memory as possible while not causing
> page swap-ins.  I understand that both page swap-outs and swap space
> usage is normal and OK, but lots of page swap-ins are bad).  In other
> words, for absolute fastest performance, we want a database buffer cache
> hit rate of as close to 100% as possible.

I'm also curious about the relationship of DB shared buffer cache to the
linux/hpux kernel caches.  In particular, if the block being retrieved in
pgsql was in the kernel's cache but not in the DB cache, thereby forcing a
read() system call, what kind of quantitative difference in performance
would one expect when comparing with block retrievals coming from the
cache?  I would think they'd differ only by something on the order of
microseconds.  Is the linux kernel disk cache normally a duplicate of much
of what is in the DB cache?  For linux, does the kernel cache use only
"available" memory until a program needs it, while the pgsql DB cache
memory is guaranteed at startup?

TIA.

Ed



pgsql-general by date:

Previous
From: Anony Mous
Date:
Subject: Two joins on same foreign key
Next
From: Gregory Wood
Date:
Subject: Re: Two joins on same foreign key