Ühel kenal päeval, K, 2006-05-31 kell 17:31, kirjutas Andreas Pflug:
> Tom Lane wrote:
> > Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >>The attached patch implements COPY ... WITH [BINARY] COMPRESSION
> >>(compression implies BINARY). The copy data uses bit 17 of the flag
> >>field to ident
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Do you have a comment about the progress notification and its impact on
> copy to stdout?
I didn't bother to comment on it because I think it's useless, as well
as broken for the stdout case. Anyone who actually sees a use for it
will have to comment o
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
The attached patch implements COPY ... WITH [BINARY] COMPRESSION
(compression implies BINARY). The copy data uses bit 17 of the flag
field to identify compressed data.
I think this is a pretty horrid idea, because it changes pg_lzcom
Andreas Pflug <[EMAIL PROTECTED]> writes:
> The attached patch implements COPY ... WITH [BINARY] COMPRESSION
> (compression implies BINARY). The copy data uses bit 17 of the flag
> field to identify compressed data.
I think this is a pretty horrid idea, because it changes pg_lzcompress
from an u
I've been playing around with COPYing large binary data, and implemented
a COMPRESSION transfer format. The server side compression saves
significant bandwidth, which may be the major limiting factor when large
amounts of data is involved (i.e. in many cases where COPY TO/FROM
STDIN/STDOUT is u