Christopher Browne wrote:
>Gavin Hamill <[EMAIL PROTECTED]> writes:
>
>
>Ideally, there should be two indexes on sl_log_1 and sl_log_2...
>
>create index sl_log_2_idx1 on @[EMAIL PROTECTED]
> (log_origin, log_xid @[EMAIL PROTECTED], log_actionseq);
>
>-- Add in an additional index as sometimes log_origin isn't a useful
>discriminant
>create index sl_log_2_idx2 on @[EMAIL PROTECTED]
> (log_xid @[EMAIL PROTECTED]);
>
>
>
OK two indexes on each of sl_log_1 and 2 giving four indexes on each node?
>I'd suggest you run either test_slony_state.pl or
>test_slony_state-dbi.pl (depending on whether you like Pg or DBI);
>those scripts rummage through the cluster looking for some common
>problems.
>
>
Anyway, from this morning, slony does appear to be maintaining itself,
the number of rows in sl_log_1 has dropped right back to 30000, so the
half-million must really be simply due to the large number of db updates
we do during our normal daily churn - I'd no idea we'd be doing that
much traffic :)
Plus the fact that the db hadn't seen a VACUUM ANALYZE in over a week
due to a broken cronjob won't have helped - whoops :)
Anyway, I'll certainly give the Perl state-tester a go - thank you
kindly {:-)
Cheers,
Gavin.
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general