Re: [PATCHES] Load distributed checkpoint patch

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Load distributed checkpoint patch
Date: 2006-12-20 16:06:46
Message-ID: 200612201606.kBKG6kE15233@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

ITAGAKI Takahiro wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > OK, if I understand correctly, instead of doing a buffer scan, write(),
> > and fsync(), and recyle the WAL files at checkpoint time, you delay the
> > scan/write part with the some delay.
>
> Exactly. Actual behavior of checkpoint is not changed by the patch. Compared
> with existing checkpoints, it just takes longer time in scan/write part.
>
> > Do you use the same delay autovacuum uses?

Sorry, I meant bgwriter delay, not autovauum.

> What do you mean 'the same delay'? Autovacuum does VACUUM, not CHECKPOINT.
> If you think cost-based-delay, I think we cannot use it here. It's hard to
> estimate how much checkpoints delay by cost-based sleeping, but we should
> finish asynchronous checkpoints by the start of next checkpoint. So I gave
> priority to punctuality over load smoothing.

OK.

> > As I remember, often the checkpoint is caused because
> > we are using the last WAL file. Doesn't this delay the creation of new
> > WAL files by renaming the old ones to higher numbers (we can't rename
> > them until the checkpoint is complete)?
>
> Checkpoints should be done by the next one, so we need WAL files for two
> checkpoints. It is the same as now.

Ah, OK, so we already reserve a full set of WAL files while we are
waiting for the checkpoint to complete.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2006-12-20 16:07:34 Re: effective_cache_size vs units
Previous Message Andrew Dunstan 2006-12-20 14:49:32 Re: [HACKERS] Enums patch v2

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-12-20 16:20:16 Re: column ordering, was Re: [PATCHES] Enums patch
Previous Message Andrew Dunstan 2006-12-20 14:49:32 Re: [HACKERS] Enums patch v2