>
>
>>prepared to implement, configure and use on a daily basis. Especially,
>>once you mix in Windows users. Let's face it. Say SSH three times fast
>>to the majority of Win32 users and let me know how many times they blink
>>while blankly staring back at you. ;)
>>
>>
>
>But "zlib" three times fast will draw a more intelligent response?
>Sorry, you're not making a coherent case at all from where I sit.
>
Although I do agree with Tom here, in that the above argument doesn't
quite make sense I disagree with the
assertion that it is not a good idea.
>The average point-and-drool Win32 user doesn't even need a database;
>he needs an application solution several levels above that.
>
Ahh that is true, but if the application solution utilizes ODBC or LibPQ
to connect to PostgreSQL
on the backend, performance becomes and issue. Not to mention lowering
traffic on a busy lan,
providing for less collisions, or a VPN connection over a 256K DSL, all
of which the compression
numbers have proved to be useful for.
>That
>application solution will incorporate components like Postgres, SSH,
>or whatever is needed. Expecting Postgres to implement functionality
>that is better served by other components is simply bad design in
>
Hmmm.... then why did we implement SSL? We could have used stunnel or
ssh for that but it
would not have been prudent. Just like adding yet another layer of
complexity to achieve something
as simple as compression between the client and server is silly.
Think of it this way. There is a reason that HTTP/1.1 supports
compression. It is the same reason
that PostgreSQL and does, at least on the Mammoth level.
Think wireless device, connecting at 19.2kbs from a thin app using the
pgsql libs, to a remote server
that maintains the data.... slow as mollasses unless compression is used.
J
>my book. We would spend our time more wisely to focus on database
>functionality that doesn't overlap with other components.
>
> regards, tom lane
>