On Thu, 2007-04-19 at 09:51 -0400, Andrew Sullivan wrote:
> On Thu, Apr 19, 2007 at 12:43:13PM +0200, Michal Taborsky - Internet Mall wrote:
> > now is, that the slon on slave issues a "fetch 100 from LOG;" command, 
> > which takes about 2 minutes to complete! The servers are loaded, but not 
> > overloaded (they are both dual-dual-core Xeons with 4G RAM).
> 
> It sounds like you need to stop all the slons, ANALYSE the log tables
> (because I bet the plans you're getting for that query are _really
> bad_), and restart, probably with a larger fetch size.  It will still
> take a long time to catch up, I expect.  But 6 million rows is by no
> means impossible -- we added 12 million rows to a table just the
> other day, and it caught up in well under an hour (mind, we had
> rather more hardware to throw at the problem than you do.  But
> still).

What we did was a bit different.  We added 12 million rows to an
un-replicated table, the subscribed the table, which wouldn't have
caused the bloated sl_log problem that Michal mentioned.  

For a table that is already replicated, if I was unable to test the
impact of slamming 6 million rows into a table that is already
replicated table, I would either load the table in batches if possible,
or look at the bulk loader tool that Andrew wrote (and posted about on
this list, I believe).

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.