On Thu, Aug 4, 2016 at 9:35 AM, Christopher Browne <cbbrowne at gmail.com> wrote:
> The observations made already wondering if there are any long-running
> transactions lurking around fit with what I'd wonder, too.  If there's
> something like a pg_dump or some long running report that holds a
> transaction open for a couple hours, that would certainly explain the
> phenomenon, and it's unfortunate that this leads to big growth of
> sl_log_*
>
> I wonder if this is a case that would get helped by BRIN indexes.
>
> Note that this is an experimental proposal I have lurking about...
>
> https://github.com/cbbrowne/slony1-engine/commit/7a02c20cde8c8f3a54914ca6889d392074d51503
>
> The index requests are (with @NAMESPACE@ as a needful schema substitution):
>
> create index sl_log_1_brin_txid on @NAMESPACE at .sl_log_1 using BRIN (log_txid);
> create index sl_log_2_brin_txid on @NAMESPACE at .sl_log_2 using BRIN (log_txid);
> create index sl_log_1_brin_action on @NAMESPACE at .sl_log_1 using BRIN
> (log_actionseq);
> create index sl_log_2_brin_action on @NAMESPACE at .sl_log_2 using BRIN
> (log_actionseq);
>
> It mightn't help, and certainly won't, if the backends aren't on
> versions supporting BRIN (only in PG 9.5+), but on the other hand, it
> might.  (And if it's a big win, that would be REALLY nice to know!
> I'll bet the folks that worked on BRIN indexes would also be happy to
> hear it!)
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


thanks Chris

I think we have looked at that, I'll have to get back to you on what
we may have found, but we won't be able to get to 9.5 for a period of
time, so we won't be much help, but I think we talked about this
internally, and again not sure what came of that discussion. We
brought up a 9.5 server in AWS and was testing there,.

Tory