"Radim Kolar SF.NET" <hsn at sendmail.cz> writes:
> small changes to slony can improve
> performance a lot during replicating over wan high-latency link.
>
> 1. fetch more than 100 lines at once becase fetching over WAN is slow
>   its easy to compute average line size and then fetch for example +- 1MB
>   of log lines. 

I don't think this will be material; the improvement is primarily in
going from 1 to 100; the improvement from going to (say) 1000 is
small, in comparison.  And I think 1.2 improved this in the logic that
deals with large tuples...

> 2. Can pgsql use gzip compression for data transfers?

Not as such; you could, however, set up pg_hba.conf on relevant nodes
to prefer SSL connections, and that will do compression.  You could
also set up an SSH tunnel, but that's more complex than configuring
SSL usage...

> not related to wan but
> 3. consider to use prepared statements for updating subscribed tables

The "better" answer would involve trying to do "peephole optimization"
on the query stream so as to group together related updates.  That
idea has been shot down pretty vigorously, at least for now.  Prepared
statements would add nearly as much complexity as "peephole
optimization," but without as much probable benefit.

(I'm saying "trust me" here; note that there have been discussion
threads where I proposed peephole optimization which were pretty
soundly thrashed as adding complexity for possibly little value...)
-- 
output = ("cbbrowne" "@" "linuxdatabases.info")
http://linuxfinances.info/info/x.html
Never take life seriously. Nobody gets out alive anyway.