http://www.slony.info/bugzilla/show_bug.cgi?id=167

           Summary: Slow down of slon with large backlog
           Product: Slony-I
           Version: devel
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: slon
        AssignedTo: slony1-bugs at lists.slony.info
        ReportedBy: janwieck at yahoo.com
                CC: slony1-bugs at lists.slony.info
   Estimated Hours: 0.0


During catch up of a major backlog, the receiving slon slows down further and
further, sometimes to a point where it cannot keep up any longer with the rate
of new changes being logged.

This is caused by a problem in the query from the remoteWorker selecting from
sl_log. The lower boundary for the log tuples is the min_xid of the first
snapshot OR the xip-vector of the first snapshot. That OR clause causes the
planner to fail to create a lower scankey for the index scan against sl_log. It
therefore always scans from the beginning with a filter condition. At some
point this becomes so expensive that it even switches to a seqscan.

The attempted fix for this will be to extract those transactions, that were in
progress at the first snapshot and are no longer in progress at the second, out
into another UNION. This will allow the plan to use a lower bound scankey for
the bulk of the log rows and pull the few transactions from the current OR
clause in with a nested loop of index scans.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.