Since you specifically asked about other solutions than the JDBC driver
itself -- we use a middle tier which makes the JDBC requests. Clients
communicate with the middle tier through non-persistent queue-based JMS
(developed in-house) which can compress the message body. This works
well for us. If you run this middle tier on the database server, the
non-compressed data doesn't go "over the wire".

Alternatively, it would probably be less than a week's work to write a
JDBC driver which just forwarded the requests to a process which used
the postgres JDBC driver to hit the database. You would essentially
forward the requests and responses, with compression around those
portions which would benefit.

Just a couple quick ideas. Maybe it'll get you thinking in a direction
that will work even better for you.

-Kevin


>>> Javier <jgagis@gmail.com> 06/17/05 11:26 AM >>>

.. . .
Last question --> Anyone knows any other way to achieve compression
with other kind of solution???
.. . .


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org