| From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Ants Aasma <ants(at)cybertec(dot)at>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Page replacement algorithm in buffer cache |
| Date: | 2013-03-23 18:51:57 |
| Message-ID: | CAOeZVid0i_F7AihZYARuYjrcW_7vGSDefHDyd6iwKtOmSOXyZQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
> Partitioned clock sweep strikes me as a bad idea... you could certainly get
> unlucky and end up with a lot of hot stuff in one partition.
>
> Another idea that'sbeen broughht up inthe past is to have something in the
> background keep a minimum number of buffers on the free list. That's how OS
> VM systems I'm familiar with work, so there's precedent for it.
>
> I recall there were at least some theoretical concerns about this, but I
> don't remember if anyone actually tested the idea.
One way to handle this could be to have dynamic membership of pages
in the partitions. Based on activity for a page, it could be moved to
another partition. In this manner, we *could* distribute the hot and
not so hot buffer pages and hence it could help.
Regards,
Atri
--
Regards,
Atri
l'apprenant
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2013-03-23 19:29:24 | Re: Page replacement algorithm in buffer cache |
| Previous Message | Tom Lane | 2013-03-23 18:34:09 | Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls |