Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
On further thought, there is one workload where removing the non-LRU
part would be counterproductive:
If you have a system with a very bursty transaction rate, it's possible
that when it's time for a checkpoint, there hasn't been any WAL logged
activity since last checkpoint, so we skip it. When that happens, the
buffer cache might still be full of dirty pages, because of hint bit
updates. That still isn't a problem on it's own, but if you then do a
huge batch update, you have to flush those dirty pages at that point. It
would be better to trickle flush those dirty pages during the idle period.
But wouldn't the LRU-based scan accomplish that?
It only scans bgwriter_lru_percent buffers ahead of the clock hand. If
the hand isn't moving, it keeps scanning the same buffers over and over
again. You can crank it all the way up to 100%, though, in which case it
would work, but that starts to get expensive CPU-wise.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
