On Thu, Jul 17, 2014 at 12:07:40PM -0400, Jan Wieck wrote:
> On 07/16/14 14:52, Christopher Browne wrote:
> > On Wed, Jul 16, 2014 at 1:14 PM, Dave Cramer <davecramer at gmail.com
> > <mailto:davecramer at gmail.com>> wrote:
> >
> >     Not sure I was clear enough. The goal is to find out what the
> >     read/write/tx profile of the application is as if slony wasn't there.
> >
> >
> > OK, that's a useful clarification.
> >
> > That makes things a bit harder, as Slony does a fair bit of activity
> > (e.g. - queries to manage events, queries to determine what data to
> > replicate,  cleanup of old data) that would also need to be accounted for.
> >
> > I'm not quite sure how to account for that load.
> >
> >     If your intent was to suggest that if we aggregated slony stats so
> >     that we could subsequently use them to get the net statistics then
> >     yes, this would work
> >
> >
> > Cool, sounds like it's a broadly helpful thing that should be helpful
> > for your case, and, I'd hope, others.
> >
> > BTW, Jan has had some thoughts about trying to run the cleanup more
> > often on the basis that if the cleanup frequency is higher than the
> > Postgres checkpoint frequency, we might be able to avoid pushing
> > sl_log_* to disk, which would mean that the cost of replication turns
> > out to be lower than people were thinking.
> 
> Correct. Not only lower in volume, but it would turn out that most of 
> the writes added by Slony go to WAL, which are sequential writes and 
> thus can often be included in just a slightly larger IO. So that would 
> be a double win.

Any ideas as to how to establish this frequency?  I'm guessing the
simplest approach would be to look at checkpoint_timeout and do
something less than that.

Up in the air is under what circumstances, if any, adjusting this
dynamically would be worthwhile.  Intuitively, in situations where
checkpoints are happening with extreme frequency, adding even more
load seems like it might be a net loss, but again that's a thing that
should be measured under a reasonable sampling of high loads, not
intuited.

Cheers,
David.
-- 
David Fetter <david at fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter at gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate