Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: =?utf-8?Q?Fabr=C3=ADcio_dos_Anjos_Silva?= <fabricio.silva@linkcom.com.br>,
	"Craig Ringer" <craig@postnewspapers.com.au>
Cc: pgsql-performance@postgresql.org
Subject: Re: How does PG know if data is in memory?
References: <AANLkTin5G0jXUbeNdC+1s9LQpk1ZpvDuX-6n90oonen3@mail.gmail.com>
	<AANLkTik5hnOcU=spN0wmWmR6_wHN=sKfVNzJeDuPTVW_@mail.gmail.com>
	<AANLkTinrtVbjtadteR88xWGGYovAzhgOWR1=pXLDi08M@mail.gmail.com>
	<4CA5D2F5.5070900@postnewspapers.com.au>
Date: Fri, 01 Oct 2010 15:45:34 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Pierre C" <lists@peufeu.com>
Message-ID: <op.vjwgh8ejeorkce@apollo13>
In-Reply-To: <4CA5D2F5.5070900@postnewspapers.com.au>
User-Agent: Opera Mail/10.62 (Linux)

> It sounds horrendously complicated to keep track of to me, and in the  
> end it won't make query execution any faster, it'll just potentially  
> help the planner pick a better plan. I wonder if that'd be worth the  
> extra CPU time spent managing the cache and cache content stats, and  
> using those cache stats when planning? It'd be an interesting  
> experiment, but the outcome is hardly obvious.

Well, suppose you pick an index scan, the only way to know which index  
(and heap) pages you'll need is to actually do the index scan... which  
isn't really something you'd do when planning. So you scan,