Message-ID: <3C4059DD.1040801@pacifier.com>
Date: Sat, 12 Jan 2002 07:44:29 -0800
From: Don Baccus <dhogaza@pacifier.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
CC: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
	Bruce Momjian <pgman@candle.pha.pa.us>, Daniel Kalchev <daniel@digsys.bg>,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: again on index usage
References: <46C15C39FEB2C44BA555E356FBCD6FA42128AD@m0114.s-mxs.net>
	<3C3F15A7.8000202@pacifier.com> <3C405168.8AEAAB8E@tm.ee>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hannu Krosing wrote:


> One radical way to get better-than-average cache behaviour in such 
> pathologigal casescases would be to discard a _random_ page instead of 
> LRU page (perhaps tuned to not not select from 1/N of pages on that are
> MRU)


Yep, that's one of the ways to improve performance when the same table's 
being scanned sequentially multiple times, or where different queries 
sometimes scan it sequentially, other times by index.  MRU would help if 
you're constantly doing sequential scans.

So would flipping the scan order depending on what's in the cache :)

But none of these would mitigate the effects on other concurrent queries 
that don't query the large table at all.


-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org