On 01/06/2014 12:43 PM, Scott Marlowe wrote:
> On Mon, Jan 6, 2014 at 12:15 PM, Jan Wieck <JanWieck at yahoo.com> wrote:
>> On 01/06/14 13:51, Brian Fehrle wrote:
>>> ...
>>>
>>> 2014-01-06 11:43:22 MST DEBUG1 remoteHelperThread_1_1: 112.859 seconds
>>> delay for first row
>>> 2014-01-06 11:43:22 MST DEBUG1 remoteHelperThread_1_1: 112.906 seconds
>>> until close cursor
>>> 2014-01-06 11:43:22 MST DEBUG1 remoteHelperThread_1_1: inserts=61
>>> updates=300 deletes=55 truncates=0
>> Almost 2 minutes to select 416 log rows? That looks wrong.
>>
>> Can you change the slon configuration to have an explain_interval? With
>> that slon will emit EXPLAIN output for the log selection query in that
>> interval. Maybe something is screwing up the optimizer.
> I always check log_1 and log_2 for bloat when these things start
> happening. Occasionally it's seqlog having a problem.
I don't see a ton of bloat on either the master or the slave. There was 
some on the slave but after a vacuum full (and reindex) we see no 
speedup in replication.


Right now I'm trying to see if I can see exactly what the events in 
sl_log are for a given event ID. How do I tie these together? I get the 
latest sync event from the view sl_status, and can see some basic info 
in sl_event, but what in there helps me tie it to the rows in 
sl_log_[1-2] so I can get an idea of just what the events are, in case 
it's something crazy big.

- Brian F