Skip site navigation (1) Skip section navigation (2)

Re: Load Distributed Checkpoints, take 3

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Load Distributed Checkpoints, take 3
Date: 2007-06-25 17:05:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> I agree with removing the non-LRU
> part of the bgwriter's write logic though; that should simplify matters
> a bit and cut down the overall I/O volume.

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.

So we might still want to keep the non-LRU scan. Or alternatively, when 
the checkpoint is a no-op, we call BufferSync nevertheless. That's 
effectively the same thing, except that BufferSync would be controlled 
by the logic to estimate the deadline until next checkpoint, instead of 
the current bgwriter_all_*-settings.

Greg, is this the kind of workload you're having, or is there some other 
scenario you're worried about?

   Heikki Linnakangas

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-06-25 17:13:46
Subject: Re: Load Distributed Checkpoints, take 3
Previous:From: Dave PageDate: 2007-06-25 15:38:57
Subject: Re: msvc and vista fun

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group