| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
| 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>, 'Atri Sharma' <atri(dot)jiit(at)gmail(dot)com>, 'Greg Stark' <stark(at)mit(dot)edu>, 'PostgreSQL-development' <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Page replacement algorithm in buffer cache |
| Date: | 2013-04-01 23:12:52 |
| Message-ID: | 515A1474.7030002@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/23/13 4:43 AM, Amit Kapila wrote:
> I have tried one of the idea's : Adding the buffers background writer finds
> reusable to freelist.
> http://www.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C382852FF97@szxeml509-mbs
> This can reduce the clock swipe as it can find buffers from freelist.
That's a nice potential efficiency gain, but it's not the same as having a separate bg process charged with keeping pages on the freelist. I believe a separate process would be useful in a wider variety of workloads, because it's not dependent on stumbling across 0 count blocks; it would actively work to "produce" zero count blocks when none existed and then free-list them.
> It shows performance improvement for read loads when data can be contained
> in shared buffers,
> but when the data becomes large and (I/O) is involved, it shows some dip as
> well.
Do you remember off-hand why it slowed down with I/O so I don't have to read the whole thread? :) Was it just a matter of it evicting dirty pages sooner than it would otherwise?
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2013-04-01 23:22:04 | Re: Page replacement algorithm in buffer cache |
| Previous Message | Jim Nasby | 2013-04-01 23:09:07 | Re: Page replacement algorithm in buffer cache |