From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | zeljko <zeljko(at)holobit(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: compressed protocol |
Date: | 2006-09-15 16:22:08 |
Message-ID: | 20060915162208.GA30889@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | zeljko | 2006-09-15 16:24:09 | Re: compressed protocol |
Previous Message | Michael Fuhr | 2006-09-15 15:52:04 | Re: compressed protocol |