On Tuesday 29 March 2005 08:22, Christopher Browne wrote:
> Rod Taylor wrote:
> >It takes me about 12 to 24 hours to copy the largest tables (that's
> >each, not collectively); so there are a number of blocks where it
> >rescans from transaction ID X to some larger number many times if I use
> >grouping sets less than 7000.
>
> That suggests to me that you might want to change the slon's -s and -t
> options a bit in order to save on the work required to generate SYNCs;
> whilst doing these subscriptions, it would probably be a _bit_ of an
> improvement to use "-s60000" so that you'd only get one SYNC per minute.
>
> If it's taking 5h to process a set of SYNCs, there is little sense in
> generating 18K sync events during that time (e.g. - one per second).
> Far better to generate 5x60, namely 300 of them.
>
> But in view of your comments, I have bumped up the sync_group_maxsize to
> 10000 for 1.1.
>
> In addition, for cases like yours, the "dynamic sync grouping" isn't
> useful, so "-o0" will turn it off.  (That's a new 1.1 thing.)
>
> The changes to the cleanup thread will doubtless be helpful to you; now,
> it checks to see if old transactions are still running (e.g. - a COPY or
> some ludicrously large SYNC group), and falls back to an ANALYZE rather
> than VACUUM ANALYZE if the same ancient transaction is blocking vacuums.
>
> I won't be messing around with the internals of the queries right now;
> that would injure stability when it would be highly desirable to get a
> 1.1.0 release out...

I have a few tuning ideas in mind as it relates to initial subscription, but 
these will all wait untill after 1.1 is out the door before I spend any real 
time on them.


> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general

-- 
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759