"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Thu, 2007-08-02 at 12:50 -0400, Tom Lane wrote:
>> Also, you should not imagine that boosting NUM_CLOG_BUFFERS has zero
>> cost. The linear searches used in slru.c start to look pretty
>> questionable if we want more than a couple dozen buffers.
> Doesn't that just beg the question: why do we have linear searches in
> slru?
Because with the designed number of buffers, that was much cheaper than
anything smarter would be. If we increase the number of buffers, we can
change to some different algorithm that is less sensitive to the number
of buffers, but it will still be slower to look up a page than it is
now. The reason I'm resisting a stampede to change this parameter is
that no one has done any work to quantify the penalty that will be paid
by scenarios other than Jignesh's one test case.
> The majority of access is going to be to the first 1-3 pages, so
> adding an array that keeps track of the LRU would be much faster anyhow.
Not sure how well that'll play with the desire for lookup operations not
to need exclusive lock (see the comments for SlruRecentlyUsed()).
In any case this is getting pretty darn far away from a one-liner patch.
I think it needs more thought and more testing than we can spare now.
regards, tom lane
