DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	b=ABgZzRI6bCvIRXjEYhA8c325NGXuOYUVv630HlQLcVk49FyrTMW+vyUrnGeRuT5+F1
	rnNvV1FQURQldfIOw7DBuDxorXcBqWgJcM4bjEkdqh780YxEl18ljEXKRCYkKRRw0rA5
	xdsVesrBePIUQXatGP7BoJ30X/JufuFEFdfHA=
Message-ID: <4A413B6D.5070200@gmail.com>
Date: Tue, 23 Jun 2009 14:30:37 -0600
From: Rob Sargent <robjsargent@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Client-side compression 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Not sure if this belongs here or on the admin or performance list.  
Apologies if so. (And this may be a second posting as the first was from 
an un-registered account.  Further apologies)

My assumption is that any de/compression done by postgres would be 
server-side.

We're considering minimizing bandwidth utilization by using client-side 
compression on a column value that will typically be multi-megabyte in 
size.  We would use ALTER TABLE SET STORAGE EXTERNAL to prevent the 
server from un-necessary compression.

Is this generally worthwhile?  I haven't found any thread on the subject 
of client-side compress so any pointer more than welcome.

Is there a great penalty for a query which delves into the value, given 
that the server will not be aware it's compressed?  I assume we're 
pretty much on our own to prevent such actions (i.e. the app can never 
query against this column via sql).