On Tue, 2005-09-27 at 17:48 -0400, Christopher Browne wrote:
> Joe Markwardt wrote:
> 
> > 2005-09-27 14:39:06 CDT DEBUG2 remoteHelperThread_1_1: 119.242 seconds
> >
> >delay for first row
> >2005-09-27 14:39:06 CDT DEBUG2 remoteHelperThread_1_1: 119.243 seconds
> >until close cursor
> >2005-09-27 14:39:06 CDT DEBUG2 remoteWorkerThread_1: new sl_rowid_seq
> >value: 1000000000000000
> >2005-09-27 14:39:06 CDT DEBUG2 remoteWorkerThread_1: SYNC 1610644 done
> >in 119.289 seconds
> >
> >I did also make the changes to the -s and -g parameters and it appears
> >to be generating syncs less often, but it doesn't really look to be
> >catching up any faster.
> >
> >postgres     12839  0.0  0.6 288840 51708 pts/3  S    14:48
> >0:00 /usr/local/pgsql/bin//slon -s 60000 -d2 -g80 pl_replication
> >host=192.168.1.200 dbname=pl
> >
> >  
> >
> Hmm.  Based on the parameters, it should be grouping sets of up to 80
> SYNCs together, and I'd see there being a BIG difference between:
> 
> a) Processing 1 SYNC in 119.289 seconds (which would seem somewhat
> crummy) and
> b) Processing 80 SYNCs in 119.289 seconds.
> 
> Oh, on 1.1, you might try turning off the "adaptive SYNC grouping"
> capability; that would involve adding the parameter "-o 0".  For
> "unusually heavy loads," that seems to have not turned out perfectly
> wonderfully :-(.
> 
I'll give that a try.  

As a side note, is there any way from the logs to determine how many
SYNCS its processing in that time frame? I have it set to -d4, just not
sure how to read the output :-)

-Joe