Re: Caching (was Re: choosing the right platform)

From: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: jim(at)nasby(dot)net, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Matthew Nuzum <cobalt(at)bearfruit(dot)org>, "'Josh Berkus'" <josh(at)agliodbs(dot)com>, "'Pgsql-Performance'" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Caching (was Re: choosing the right platform)
Date: 2003-04-10 18:59:55
Message-ID: 3E95BF2B.B93FD0EF@nsd.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

How can we solve the problem of cache trashing when scanning large
tables?

Tom Lane wrote:
>
> Jean-Luc Lachance <jllachan(at)nsd(dot)ca> writes:
> > Shouldn't there be a way to lock some tables in PG cache?
>
> In my opinion, no. I do not think a manual locking feature could
> possibly be used effectively. It could very easily be abused to
> decrease net performance, though :-(
>
> It does seem that a smarter buffer management algorithm would be a good
> idea, but past experiments have failed to show any measurable benefit.
> Perhaps those experiments were testing the wrong conditions. I'd still
> be happy to see LRU(k) or some such method put in, if someone can prove
> that it actually does anything useful for us. (As best I recall, I only
> tested LRU-2 with pgbench. Perhaps Josh's benchmarking project will
> offer a wider variety of interesting scenarios.)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ron Mayer 2003-04-10 23:06:40 Re: Caching (was Re: choosing the right platform)
Previous Message Patrick Hatcher 2003-04-10 18:52:45 Re: Slow Visual Basic application