Re: [HACKERS] copy with compression progress n

2006-06-01 Thread Hannu Krosing
Ü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 identify compressed

[HACKERS] copy with compression progress n

2006-05-31 Thread Andreas Pflug
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

Re: [HACKERS] copy with compression progress n

2006-05-31 Thread Tom Lane
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

Re: [HACKERS] copy with compression progress n

2006-05-31 Thread 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 identify compressed data. I think this is a pretty horrid idea, because it changes

Re: [HACKERS] copy with compression progress n

2006-05-31 Thread Tom Lane
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 on