Re: old synchronized scan patch

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> On Tue, 2006-12-05 at 13:25 -0500, Tom Lane wrote:
>> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> > "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> >> Sure, it should hang around for awhile, and will. The problem is that
>> >> its lifetime will be artificially inflated, so that the seqscan ends up
>> >> kicking out other blocks that are really of greater importance, rather
>> >> than recycling its own old blocks as it should.
>>
>> > I thought you had switched this all to a clock sweep algorithm.
>>
>> Yeah ... it's a clock sweep with counter. A buffer's counter is
>> incremented by each access and decremented when the sweep passes over
>> it. So multiple accesses allow the buffer to survive longer. For a
>> large seqscan you really would rather the counter stayed at zero,
>> because you want the buffers to be recycled when the sweep comes back
>> the first time.
>
> If you focus the backends together by synchronizing them you definitely
> also then need to solve the problem of false cache reinforcement.

Well the clock sweep algorithm is inherently resistant to this. The classical
algorithm only had a single bit to indicate whether the buffer had been
touched since hand came around last.

If you have a counter you just need to limit the size of that counter. The
larger the maximum value of the counter the slower the algorithm will be to
learn new access patterns. The smaller the counter is the shorter its memory
will be.

I do vaguely recall discussing having a counter in school but IIRC it was just
a two bit counter which the clock sweep shifted right. So a buffer hit by a
synchronized would require two sweeps to get flushed instead of one but that
would be true regardless of how many synchronized scans hit it.

I think the no-counter (ie, single bit of state) is probably exactly what you
want in this case. If there are synchronized scans running there may be more
coming along behind you. You do want to keep those buffers around long enough
to be used by them. If there aren't any synchronized scans running then you
probably want to just keep reusing the same buffers which is what will happen
when the hand comes around the next time if nobody else has looked at.

It may be enough to just cap the use-counter at different values when you
increment it depending on the type of access. In a sequential scan don't
increment it beyond 1 (ie, just a single bit of state). In a random I/O
increment it up to 2. It may also be useful to have different initial use
values. Or maybe it makes more sense to look at initial values. If you load a
buffer in a sequential scan perhaps its use count could start at 0 whereas
random i/o could start at 1.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com