From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] COPY .. COMPRESSED |
Date: | 2013-01-16 23:19:09 |
Message-ID: | CA+TgmoZEWaTAoXm8STcFP6rEa3rNBQFaLL=h8cWzSut+CDyr7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I find the argument that this supports compression-over-the-wire to be
> quite weak, because COPY is only one form of bulk data transfer, and
> one that a lot of applications don't ever use. If we think we need to
> support transmission compression for ourselves, it ought to be
> integrated at the wire protocol level, not in COPY.
>
> Just to not look like I'm rejecting stuff without proposing
> alternatives, here is an idea about a backwards-compatible design for
> doing that: we could add an option that can be set in the connection
> request packet. Say, "transmission_compression = gzip".
But presumably this would transparently compress at one end and
decompress at the other end, which is again a somewhat different use
case. To get compressed output on the client side, you have to
decompress and recompress. Maybe that's OK, but it's not quite the
same thing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-01-16 23:25:49 | Re: [PATCH] COPY .. COMPRESSED |
Previous Message | Tom Lane | 2013-01-16 23:14:41 | Re: Event Triggers: adding information |