On 3/4/2005 2:11 PM, James Black wrote:

> I'll answer for Christian, who's at lunch:
> 
> -[ RECORD 1 ]-------------+---------------------------
> st_origin                 | 1
> st_received               | 2
> st_last_event             | 4286054
> st_last_event_ts          | 2005-03-04 11:11:24.78657
> st_last_received          | 4286032
> st_last_received_ts       | 2005-03-04 11:11:04.63196
> st_last_received_event_ts | 2005-03-04 11:10:48.52362
> st_lag_num_events         | 22
> st_lag_time               | 00:00:41.702335
> -[ RECORD 2 ]-------------+---------------------------
> st_origin                 | 1
> st_received               | 3
> st_last_event             | 4286054
> st_last_event_ts          | 2005-03-04 11:11:24.78657
> st_last_received          | 4286038
> st_last_received_ts       | 2005-03-04 11:11:11.175203
> st_last_received_event_ts | 2005-03-04 11:11:01.917055
> st_lag_num_events         | 16
> st_lag_time               | 00:00:28.3089
> 

375000 log rows and no subscriber more than 40 seconds behind ... that 
looks like someone was doing mass updates here.

How many sets are there? There have been reports that a large number of 
sets to replicate can screw the optimizer so that it will do a seq scan 
on the sl_log_1 table and once enough data has accumulated there, the 
performance gets worse and worse.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #