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...