Re: trace_checkpoint parameter patch - Mailing list pgsql-patches

From Satoshi Nagayasu
Subject Re: trace_checkpoint parameter patch
Date
Msg-id 466F2CD3.4040607@nttdata.co.jp
Whole thread Raw
In response to trace_checkpoint parameter patch  (Satoshi Nagayasu <snaga@snaga.org>)
List pgsql-patches
Greg,

Thanks for comments.

Greg Smith wrote:
> The idea of using pg_rusage_init is a new one though; I hadn't thought the
> CPU usage info was interesting enough to figure out how to collect it.
> The way the patch mentioned above works it would be hard to squeeze it in
> the line usefully for formatting reasons.

"trace_sort" option uses the pg_rusage_init(), so my "trace_checkpoint"
also uses it.

> I don't know what's wrong, but the I/O here is pretty simple:  the
> checkpoint wrote some amount of data that you can compute the size of
> easily within the code knowing the block size.  That's already done in the
> patch under review.

Cool.

> If you're interested in this area, you should check out the
> pg_stat_bgwriter feature already in the 8.3 CVS, look through the
> pgsql-hackers archives for the discussion this week on the topic
> "Controlling Load Distributed Checkpoints", and check out the "Automatic
> adjustment of bgwriter_lru_maxpages" patch whose latest version is at
> http://archives.postgresql.org/pgsql-patches/2007-05/msg00142.php

Thanks for the information. I missed that thread.

But I'm not so much interested in huge modification on the checkpoint now.
I need just some information on checkpointing to tune my config by my hand.
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
Phone: +81-50-5546-2496


pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] COPYable logs status
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] COPYable logs status