From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Log levels for checkpoint/bgwriter monitoring |
Date: | 2007-03-06 15:39:06 |
Message-ID: | E1B40D86-CAD1-4602-AAF6-064F84A6DFD2@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 5, 2007, at 8:34 PM, Greg Smith wrote:
> On Thu, 22 Feb 2007, Jim C. Nasby wrote:
>
>> It would also be extremely useful to make checkpoint stats visible
>> somewhere in the database (presumably via the existing stats
>> mechanism)... I'm thinking just tracking how many pages had to be
>> flushed during a checkpoint would be a good start.
>
> I'm in the middle of testing an updated version of the patch, once
> I nail down exactly what needs to be logged I'd planned to open a
> discussion on which of those things would be best served by
> pg_stats instead of a log.
>
> I decided specifically to aim for the logs instead for the
> checkpoint data because if you're in a situation where are
> inserting fast enough that the checkpoints are spaced closely
> together, you'd end up having to poll pg_stats all the time for
> make sure you catch them all, which becomes even less efficient
> than just logging the data.
It's always good to be able to log stuff for detailed
troubleshooting, so that's a good place to start. The flipside is
that it's much easier to machine-parse a table rather than trying to
scrape the logs. And I don't think we'll generally care about each
individual checkpoint; rather we'll want to look at things like
'checkpoints/hour' and 'checkpoint written pages/hour'.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2007-03-06 15:48:19 | Calculated view fields (8.1 != 8.2) |
Previous Message | Teodor Sigaev | 2007-03-06 15:14:40 | Re: user-defined tree methods in GIST |