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
sthomas@xxxxxxxxxxxxxxxx
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
