> -----Original Message-----
> From: Jim Nasby [mailto:jim@nasby.net]
> Sent: Tuesday, April 02, 2013 4:43 AM
> To: Amit Kapila
> Cc: 'Ants Aasma'; 'Merlin Moncure'; 'Tom Lane'; 'Atri Sharma'; 'Greg
> Stark'; 'PostgreSQL-development'
> Subject: Re: [HACKERS] 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 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.
If bg process work to produce zero count blocks, then wouldn't it give more
priority to
reduce usage count without any demand, or would you like to do the work in
bg process
based on some statistics for buffer usage.
> > 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? :)
You can go through below mail to read some of my observation regarding the
performance improvement
http://www.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C383BC76A4
C@szxeml509-mbx
For case when I/O is involved you can once check the readings in below mail:
http://www.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C383BC76A4
C@szxeml509-mbx
> Was it just a matter of it evicting dirty pages sooner than it would
otherwise?
The exact reason was not nailed down, but as it is I/O heavy test, there is
some chance that OS scheduling also would have played role.
The reason I think why OS can be involved, because when we are flushing
buffers internally OS also might change their usage count based on access of
buffer.
The other could be as pointed out by you, early eviction.
With Regards,
Amit Kapila.