Message-ID: <4CB52489.8050309@cheapcomplexdevices.com>
Date: Tue, 12 Oct 2010 20:16:25 -0700
From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: pgsql-performance@postgresql.org, gnuoytr@rcn.com,
	Ron Mayer <rm_pg@cheapcomplexdevices.com>
Subject: Re: How does PG know if data is in memory?
References: <AANLkTin5G0jXUbeNdC+1s9LQpk1ZpvDuX-6n90oonen3@mail.gmail.com>
	<4CA9488C.2080502@2ndquadrant.com> <4CAA5974.2050805@wizmail.org>
	<AANLkTi=gBcvy2_Ey2q_gaiyUOjrGU4LoYfdbO9uxEZDX@mail.gmail.com>
	<20101011231134.ANB76937@ms14.lnh.mail.rcn.net>
	<4CB42BFC0200002500036805@gw.wicourts.gov>
In-Reply-To: <4CB42BFC0200002500036805@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Kevin Grittner wrote:
>  
> ...Sybase named caches...segment off portions of the memory for
> specific caches... bind specific database
> objects (tables and indexes) to specific caches. ...
>  
> When I posted to the list about it, the response was that LRU
> eviction was superior to any tuning any human would do.  I didn't
> and don't believe that....
>  
> FWIW, the four main reasons for using it were:
> (1) Heavily used data could be kept fully cached in RAM...

Lightly-used-but-important data seems like another use case.

LRU's probably far better than me at optimizing for the total
throughput and/or average response time.  But if there's a
requirement:
 "Even though this query's very rare, it should respond
  ASAP, even at the expense of the throughput of the rest
  of the system."
it sounds like this kind of hand-tuning might be useful.