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

Re: [PATCH] COPY .. COMPRESSED

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: 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-15 23:17:05
Message-ID: 5504.1358291825@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Really?  Given that libpq provides no useful support for doing anything
>> with COPY data, much less higher-level packages such as Perl DBI, I'd
>> venture that the real-world ratio is more like 90/10.  If not 99/1.

> Perhaps I'm taking a bit too narrow view of the world, but my thinking
> is OLTP won't want things compressed, as it increases latency of
> requests, while OLAP users are operating with enough data that they'll
> go through the effort to use COPY.

I should think the argument for or against wire-protocol compression
depends mainly on your network environment, not the nature of your
application.  Either bytes sent are more expensive than CPU cycles at
each end, or vice versa.  Latency could be a big deal if we weren't
going to force compressor flushes at synchronization boundaries, but
if we are, any added latency is a matter of a few cycles at most.

			regards, tom lane


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2013-01-15 23:19:27
Subject: Re: Parallel query execution
Previous:From: Stephen FrostDate: 2013-01-15 23:15:57
Subject: Re: Parallel query execution

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