| 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: | Whole Thread | Raw Message | 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 |