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.
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
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@nasby.net
512.569.9461 (cell) http://jim.nasby.net

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 51 of 82 | next ›
Discussion Overview
grouppgsql-hackers @
postedMar 22, '13 at 4:52a
activeApr 9, '13 at 7:07a



site design / logo © 2021 Grokbase