Michael Fuhr wrote: > On Fri, Sep 15, 2006 at 09:52:04AM -0600, Michael Fuhr wrote: >> On Fri, Sep 15, 2006 at 05:37:50PM +0200, zeljko wrote: >> > But, when I try (via tunnel, explained above) >> > psql -p 5400 -h localhost mydatabase >> > it connects and works fine, but there's no compression. >> > Query returns in cca 20 seconds, almost same (maybe 0.5 sec. different) >> > as normal psql connection.Conclusion is that there's no compression of >> > psql stream. Returned data is varchars and integers. >> >> That's a tenuous conclusion; it assumes that the data transfer is >> what's taking all the time. Query planning and execution and >> client-side processing must also be taken into account. Using a >> sniffer to observe the amount of data transferred would be a more >> appropriate test. > > Also, don't discount the amount of time that compressing and > decompressing takes. The ls and psql tests aren't necessarily > comparable due to differing amounts and characteristics of data. > > I just ran some tests between a couple of boxes on a local network, > using psql over a tunneled ssh connection as you are. A sniffer > showed that a compressed connection transferred 54% of the amount > of data as an uncompressed connection but it took 69% longer to do > so. If the network is fast and the boxes are slow then a compressed > connection can be a net loser. > I'm testing over DSL line (test server have 256k Upload and 1MB download). Results are based on this connection. Server : PIV 3Ghz HT, 1GB RAM. (DSL D 1MB U 256k) Client : PIV 3Ghz HT, 1GB RAM. (DSL D 3MB U 384k). nTier results shows real compression (faster more than twice).
