Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] COPY .. COMPRESSED

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] COPY .. COMPRESSED
Date: 2013-01-14 16:01:06
Message-ID: 20130114160106.GJ16126@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> There is a new option being added to pre/post process data, so it
> seems like the best way to add new features - in general.

That structure appears to have no option for passing compressed data to
or from a client connection.  Instead, it actually overloads the typical
meaning for options sent to \copy (which, imv, is "run COPY on the server
with these options and have the results stored locally") to mean
something different (run part of the COPY command on the server and part
of it locally).

> Specifically, we do support compressed output so a simple patch to
> allow re-loading of the compressed data we generate does seem sensible
> and reasonable.

Right, we're already using gzip for pg_dump/pg_restore.  This just gives
an option to move that compression over to the server side.  Also, I'd
be happy to add support for other compression options.

I do like the idea of a generalized answer which just runs a
user-provided command on the server but that's always going to require
superuser privileges.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2013-01-14 16:02:40
Subject: Re: erroneous restore into pg_catalog schema
Previous:From: Thom BrownDate: 2013-01-14 15:48:57
Subject: Re: pg_ctl idempotent option

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group