Re: [PATCH] COPY .. COMPRESSED
От | Robert Haas |
---|---|
Тема | Re: [PATCH] COPY .. COMPRESSED |
Дата | |
Msg-id | CA+TgmoZEWaTAoXm8STcFP6rEa3rNBQFaLL=h8cWzSut+CDyr7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] COPY .. COMPRESSED (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] COPY .. COMPRESSED
Re: [PATCH] COPY .. COMPRESSED |
Список | pgsql-hackers |
On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: