Hey everyone, Frankly, I'm shocked at what I just found.
We did a delete last night of a few million rows, and come back this morning to find that slony is 9-hours behind. After some investigation, it became apparent that slony opens up a cursor and orders it by the log_actionseq column. Then it fetches 500 rows, and closes the cursor. So it's fetching several million rows into a cursor, to fetch 500, and then throw the rest away.
That is quite possibly the least efficient manner I could think of to build a sync system, so maybe someone knows why they did it that way?
At least with a regular query, it could sort by the column it wanted, and put a nifty index on it for those 500-row chunks it's grabbing. I must be missing something...
Yeah, I know... millions of rows + slony = bad. But it doesn't have to be *this* bad. Even a few hundred thousand rows would be terrible with this design.
I plan on asking the slony guys too, but I figured someone on this list might happen to know.
Looks like I might have to look into Bucardo or Londiste. Thanks! -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general