|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: Load distributed checkpoint patch|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
ITAGAKI Takahiro wrote:
> This is a patch for load distributed checkpoint discussed in
> Only write() calls are smoothed, fsync() are not.
> Existing checkpoint method is called "immediate checkpoint" in the patch,
> and the new method called "asynchronous checkpoint".
> I'm working on more robust control of checkpoint progress. WAL are written
> a lot just after checkpoints because of full-page-writes and decreases
> gradually. Linear control seems to be not enough in some cases.
> Comments, suggestions and testing are appreciated.
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. Do you use the same delay
autovacuum uses? 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)?
Bruce Momjian bruce(at)momjian(dot)us
+ If your life is a hard drive, Christ can be your backup. +
|Next Message||Bruce Momjian||2006-12-19 17:01:44||Re: Autovacuum Improvements (was: Second attempt,|
|Previous Message||Stephen Frost||2006-12-19 16:59:32||ERROR: tuple concurrently updated|
|Next Message||Tom Dunstan||2006-12-20 01:23:02||Re: Enums patch v2|
|Previous Message||Martijn van Oosterhout||2006-12-19 16:25:04||Re: column ordering, was Re: [PATCHES] Enums patch v2|