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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
