Re: Page replacement algorithm in buffer cache

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
pageson the freelist. I believe a separate process would be useful in a wider variety of workloads, because it's not
dependenton stumbling across 0 count blocks; it would actively work to "produce" zero count blocks when none existed
andthen 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
ofit evicting dirty pages sooner than it would otherwise?
 
--
Jim C. Nasby, Data Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net