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
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 |