Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-04-05 Thread Peter Geoghegan
On 3 April 2012 12:11, Robert Haas robertmh...@gmail.com wrote: Well, for 9.2, I am asking that you rip all that stuff out of the patch altogether so we can focus on the stuff that was in the original patch. Given how we're pushed for time, I'm inclined to agree that that is the best course of

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-04-05 Thread Jeff Janes
On Wed, Mar 28, 2012 at 7:23 AM, Robert Haas robertmh...@gmail.com wrote: Although I liked the idea of separating this out, I wasn't thinking we should do it as part of this patch.  It seems like an independent project.  At any rate, I strongly agree that counting the number of strategy

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-04-05 Thread Robert Haas
On Thu, Apr 5, 2012 at 9:05 AM, Peter Geoghegan pe...@2ndquadrant.com wrote: On 3 April 2012 12:11, Robert Haas robertmh...@gmail.com wrote: Well, for 9.2, I am asking that you rip all that stuff out of the patch altogether so we can focus on the stuff that was in the original patch. Given

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-04-03 Thread Robert Haas
On Sat, Mar 31, 2012 at 5:34 PM, Peter Geoghegan pe...@2ndquadrant.com wrote: Since any backend write is necessarily the result of that backend trying to allocate a buffer, I think maybe we should just count whether the number of times it was trying to allocate a buffer *using a BAS* vs. the

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-03-31 Thread Peter Geoghegan
On 28 March 2012 15:23, Robert Haas robertmh...@gmail.com wrote:  At any rate, I strongly agree that counting the number of strategy allocations is not really a viable proxy for counting the number of backend writes.  You can't know how many of those actually got dirtied. Sure. Since any

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-03-28 Thread Robert Haas
On Thu, Mar 22, 2012 at 6:07 PM, Peter Geoghegan pe...@2ndquadrant.com wrote: On 23 January 2012 02:08, Robert Haas robertmh...@gmail.com wrote: On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes jeff.ja...@gmail.com wrote: I'm finding the backend_writes column pretty unfortunate.  The only use I

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-03-22 Thread Peter Geoghegan
On 23 January 2012 02:08, Robert Haas robertmh...@gmail.com wrote: On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes jeff.ja...@gmail.com wrote: I'm finding the backend_writes column pretty unfortunate.  The only use I know of for it is to determine if the bgwriter is lagging behind.  Yet it doesn't

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-03-09 Thread Robert Haas
On Wed, Feb 22, 2012 at 2:11 PM, Peter Geoghegan pe...@2ndquadrant.com wrote: One beef that I have with the variable name m_write_ms is that ms could equally well refer to microseconds or milliseconds, and these mistakes are very common. I would expect ms to mean milliseconds and us to mean

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-02-22 Thread Peter Geoghegan
On 16 January 2012 06:28, Greg Smith g...@2ndquadrant.com wrote: One of the most useful bits of feedback on how well checkpoint I/O is going is the amount of time taken to sync files to disk.  Right now the only way to get that is to parse the logs.  The attached patch publishes the most

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-23 Thread Greg Smith
Robert Haas wrote: On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes jeff.ja...@gmail.com wrote: I'm finding the backend_writes column pretty unfortunate. The only use I know of for it is to determine if the bgwriter is lagging behind. Yet it doesn't serve even this purpose because it lumps

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-22 Thread Greg Smith
Jeff Janes wrote: I'm finding the backend_writes column pretty unfortunate. The only use I know of for it is to determine if the bgwriter is lagging behind. Yet it doesn't serve even this purpose because it lumps together the backend writes due to lagging background writes, and the backend

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-22 Thread Robert Haas
On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes jeff.ja...@gmail.com wrote: I'm finding the backend_writes column pretty unfortunate.  The only use I know of for it is to determine if the bgwriter is lagging behind.  Yet it doesn't serve even this purpose because it lumps together the backend

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-21 Thread Jeff Janes
On Sun, Jan 15, 2012 at 10:28 PM, Greg Smith g...@2ndquadrant.com wrote: I would like to be able to tell people they need never turn on log_checkpoints if they monitor pg_stat_bgwriter instead, because that sets a good precedent for what direction the database is going.  It would be nice for

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-19 Thread Hitoshi Harada
On Sun, Jan 15, 2012 at 10:46 PM, Greg Smith g...@2ndquadrant.com wrote: On 01/16/2012 01:28 AM, Greg Smith wrote: -I can't tell for sure if this is working properly when log_checkpoints is off.  This now collects checkpoint end time data in all cases, whereas before it ignored that work if

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-19 Thread Alvaro Herrera
Excerpts from Hitoshi Harada's message of jue ene 19 07:08:52 -0300 2012: On Sun, Jan 15, 2012 at 10:46 PM, Greg Smith g...@2ndquadrant.com wrote: On 01/16/2012 01:28 AM, Greg Smith wrote: -I can't tell for sure if this is working properly when log_checkpoints is off.  This now collects

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-19 Thread Robert Haas
On Mon, Jan 16, 2012 at 1:28 AM, Greg Smith g...@2ndquadrant.com wrote: One of the most useful bits of feedback on how well checkpoint I/O is going is the amount of time taken to sync files to disk.  Right now the only way to get that is to parse the logs.  The attached patch publishes the most

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-19 Thread Simon Riggs
On Thu, Jan 19, 2012 at 3:52 PM, Robert Haas robertmh...@gmail.com wrote: And, it doesn't seem like it's necessarily going to safe me a whole lot either, because if it turns out that my sync phases are long, the first question out of my mouth is going to be what percentage of my total sync

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-19 Thread Greg Smith
On 01/19/2012 10:52 AM, Robert Haas wrote: It's not quite clear from your email, but I gather that the way that this is intended to work is that these values increment every time we checkpoint? Right--they get updated in the same atomic bump that moves up things like buffers_checkpoint

[HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-15 Thread Greg Smith
One of the most useful bits of feedback on how well checkpoint I/O is going is the amount of time taken to sync files to disk. Right now the only way to get that is to parse the logs. The attached patch publishes the most useful three bits of data you could only get from log_checkpoints

Re: [HACKERS] Publish checkpoint timing and sync files summary data to pg_stat_bgwriter

2012-01-15 Thread Greg Smith
On 01/16/2012 01:28 AM, Greg Smith wrote: -I can't tell for sure if this is working properly when log_checkpoints is off. This now collects checkpoint end time data in all cases, whereas before it ignored that work if log_checkpoints was off. ...and there's at least one I missed located