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

Re: Proposed patch to change TOAST compression strategy

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgreSQL(dot)org
Subject: Re: Proposed patch to change TOAST compression strategy
Date: 2008-02-20 21:14:58
Message-ID: 47BC9852.9010100@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-patches
On 2/18/2008 5:33 AM, Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 
>> * Adds an early-failure path to the compressor as suggested by Jan:
>> if it's been unable to find even one compressible substring in the
>> first 1KB (parameterizable), assume we're looking at incompressible
>> input and give up.  (There are various ways this could be done, but
>> this way seems to add the least overhead to the compressor's inner
>> loop.)
> 
> I'm not sure how to test the rest of it, but this bit seems testable. I fear
> this may be too conservative. Even nigh incompressible data will find a few
> backreferences.

One could argue that storing JPEG in a bytea column and not configuring 
the column to skip compression is a pilot error. But I guess this 
happens much more often than accidentally finding some data that has 
zero backref within the first KB and changes pattern thereafter. Do you 
have any example for data that is like that?


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin


In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2008-02-20 22:55:06
Subject: Re: BUG #3973: pg_dump using inherited tables do not always restore
Previous:From: Alex HunsakerDate: 2008-02-20 21:03:29
Subject: BUG #3973: pg_dump using inherited tables do not always restore

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