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 j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
