Amit Kumar Khare <skamit2000@yahoo.com> writes:
> (4)what I think the problem arises because of default LRU page
> replacement policy. So I think we have to make use of MRU or LRU-K
> page replacement policies.
> (5)But I am not sure and I wish more input into the problem
> description from you all. I have started reading the buffer manager
> code and I found that freelist.c may be needed to be modified and may
> be some other too since we have to identify the large sequential
> scans.
I do not think it's a good idea for the buffer manager to directly try
to recognize sequential scans; any such attempt will fall down on the
fundamental problem that there may be more than one backend accessing
the same table concurrently. Plus it would introduce undesirable
coupling between the buffer manager and higher-level code. I like the
idea of using LRU-K or other advanced page replacement policies,
instead of plain LRU.
I did some experimentation with LRU-2 awhile back and didn't see any
measurable performance improvement in the small number of test cases
I tried. But I was not looking at the issue of cache-flushing caused
by large seqscans (the test cases I tried probably didn't do any
seqscans at all). It's quite possible that that's a sufficient reason
to adopt LRU-2 anyway.
regards, tom lane
