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

Re: Load Distributed Checkpoints, take 3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Load Distributed Checkpoints, take 3
Date: 2007-06-22 20:21:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Ok, if we approach this from the idea that there will be *no* GUC 
> variables at all to control this, and we remove the bgwriter_all_* 
> settings as well, does anyone see a reason why that would be bad? Here's 
> the ones mentioned this far:

> 1. we need to keep 2x as much WAL segments around as before.

No, only 50% more.  We've always kept WAL back to the
checkpoint-before-last, so the peak usage has been about 2 checkpoint
distances (plus a bit), and now it'd tend to be about 3.

> 2. pg_start_backup will need to wait for a long time.

> 3. Recovery will take longer, because the distance last committed redo 
> ptr will lag behind more.

True, you'd have to replay 1.5 checkpoint intervals on average instead
of 0.5 (more or less, assuming checkpoints had been short).  I don't
think we're in the business of optimizing crash recovery time though.

It might be that getting rid of checkpoint_smoothing is an overreaction,
and that we should keep that parameter.  IIRC Greg had worried about
being able to turn this behavior off, so we'd still need at least a
bool, and we might as well expose the fraction instead.  (Still don't
like the name "smoothing" though.)  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.

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-06-22 20:46:51
Subject: Re: Load Distributed Checkpoints, take 3
Previous:From: Greg SmithDate: 2007-06-22 18:40:30
Subject: Re: Load Distributed Checkpoints, take 3

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