From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Are there plans to add data compression feature to postgresql? |
Date: | 2008-11-03 01:54:18 |
Message-ID: | 490E59CA.5070309@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
>> Wire protocol compression support in PostgreSQL would probably still be
>> extremely useful for Internet or WAN based clients, though,
>
> Use an ssh tunnel ... get compression *and* encryption, which you surely
> should want on a WAN link.
An ssh tunnel, while very useful, is only suitable for more capable
users and is far from transparent. It requires an additional setup step
before connection to the database that's going to cause support problems
and confuse users. It's also somewhat painful on Windows machines.
Additionally, use of an SSH tunnel makes recovery after a connection is
broken much, MUCH more difficult for an application to handle
transparently automatically.
As you know, PostgreSQL supports SSL/TLS for encryption of wire
communications, and you can use client certificates as an additional
layer of authentication much as you can use an ssh key. It's clean and
to the end user it's basically transparent. All the major clients, like
the ODBC and JDBC drivers, already support it. Adding optional
compression within that would be wonderful - and since the client and
server are already designed to communicate through filters (for
encryption) it shouldn't be that hard to stack another filter layer on top.
It's something I'm going to have to look at myself, actually, though I
have some work on the qemu LSI SCSI driver that I *really* have to
finish first.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-11-03 01:59:32 | Re: Performance of views |
Previous Message | Stephen Frost | 2008-11-03 01:39:14 | Re: Performance of views |