On Wed, 2007-05-16 at 15:10 -0500, Don Barthel wrote:
> I have some big/complicated indexes on one particular table and since
> I have lots of memory to spare I've just now increased my
> shared_buffers from 20000 to 40000 (and SHMMAX at the OS level
> appropriately) and reload'ed postgresql but things are still
> progressing slowly.
> 

Shared buffers on the origin or the subscriber? Shared buffers might not
matter in this case anyway.

A Slony subscriber reads from the log on the origin and then writes the
records on the subscriber in separate statements. For any bulk operation
on the origin (like a big UPDATE statement) that translates into a lot
of little statements on the subscriber. Usually, each of those little
statements uses an index, because that's fastest for an action on a
single tuple.

If you don't have enough memory to hold the index, that translates into
bad performance.

Tell us more about the situation. Is the index fitting in shared memory?
How big is the table? How much physical memory? Try to hunt down which
events are taking a long time to SYNC. What other types of bulk
operations are you doing? Any big UPDATEs or DELETEs?

Regards,
	Jeff Davis