Joe Markwardt wrote:

>On Wed, 2005-09-28 at 01:20 +0300, Hannu Krosing wrote:
>  
>
>>On T, 2005-09-27 at 16:37 -0500, Joe Markwardt wrote:
>>
>>    
>>
>>>Yep.  And I restarted the slon's as well, so they should be using the
>>>index as long as the planner thinks it will help.  Is there anyway I can
>>>see the query that slon is generating to create the cursor? If I could
>>>see that query then I could do some explain analyze's and see what they
>>>say...
>>>      
>>>
>>I usually look at the queries in postgres log.
>>
>>In your case you could set up postgres to log only long queries, say
>>over 50 sec, and then just tail -f the log.
>>
>>When analysing take notice that slon specially sets enable_seqsnam and
>>enable_indexscan before running the query on sl_log_1.
>>
>>    
>>
>Thanks for the tip, but the only queries that are being logged are the
>FETCH statements...I suppose I could set it up to log all queries (and
>plans) and then restart slon, then turn off the query logging.
>  
>
Right you are...

The interesting query is the one that sets up the cursor, and it doesn't
take long :-(.

You can tell how many SYNCs are being processed together by looking at
two consecutive lines that say "SYNC XXXX done in Y.xyz seconds"

(They'll have lines in between...)

If it's "SYNC 1610644 done in 119 seconds" followed (2 minutes later) by
"SYNC 1610724 done in 119 seconds", then you know that it's doing groups
of 80, and even if it's not catching up quickly, that's at least the
right direction to go in.