>>> On Thu, Sep 27, 2007 at 6:56 AM, in message <[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]> wrote: > On Wed, 2007-09-26 at 16:31 -0500, Kevin Grittner wrote: > >> The one downside I've found is that it adds 0.2 >> seconds of CPU time per WAL file archive during our heaviest update >> periods. > > OK, first time anybody's measured a significant cost to process creation > during execution of the archive_command. Still fairly low though. Since it's that unusual, I'll check it closely during more "normal" testing. The timings so far are against old WAL files on the box running 72 warm standby instances and actively running rsync against all of the sources. Perhaps the unusual load somehow distorted the measurement. I based this on running a gzip of various WAL files versus the filter piped to gzip; writing to a file in both cases, and using "time" to get the metrics. Any suggestions for different or better ways to measure the impact are welcome. -Kevin
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
