Re: old synchronized scan patch
От | Gregory Stark |
---|---|
Тема | Re: old synchronized scan patch |
Дата | |
Msg-id | 874ps8km81.fsf@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: old synchronized scan patch ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: old synchronized scan patch
("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
|
Список | pgsql-hackers |
"Simon Riggs" <simon@2ndquadrant.com> writes: > On Tue, 2006-12-05 at 13:25 -0500, Tom Lane wrote: >> Gregory Stark <stark@enterprisedb.com> writes: >> > "Tom Lane" <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: