<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 16, 2014 at 1:14 PM, Dave Cramer <span dir="ltr"><<a href="mailto:davecramer@gmail.com" target="_blank">davecramer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. </div>
</blockquote><div><br></div><div>OK, that's a useful clarification.</div><div><br></div><div>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.</div>
<div><br></div><div>I'm not quite sure how to account for that load.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>
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</div></div></blockquote><div><br></div><div>Cool, sounds like it's a broadly helpful thing that should be helpful for your case, and, I'd hope, others.</div>
<div><br></div><div>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.</div>
</div></div></div>