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

Re: Repair cosmetic damage (done by pg_indent?)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Decibel!" <decibel(at)decibel(dot)org>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Repair cosmetic damage (done by pg_indent?)
Date: 2007-08-04 20:04:33
Message-ID: 877iobkqwe.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> The scenario I was describing was having, for example, 20 fields each
>> of which are char(100) and store 'x' (which are padded with 99
>> spaces). So the row is 2k but the fields are highly compressible, but
>> shorter than the 256 byte minimum.
>
> To be blunt, the solution to problems like that is sending the DBA to a
> re-education camp.  I don't think we should invest huge amounts of
> effort on something that's trivially fixed by using the correct datatype
> instead of the wrong datatype.

Sorry, there was a bit of a mixup here. The scenario I described above is what
it would take to get Postgres to actually try to compress a small string given
the way the toaster works. 

In the real world interesting cases wouldn't be so extreme. Having a single
CHAR(n) or a text field which contains any other very compressible string
could easily not be compressed currently due to being under 256 bytes.

I think the richer target here is doing some kind of cross-record compression.
For example, xml text columns often contain the same tags over and over again
in successive records but any single datum wouldn't be compressible.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


In response to

Responses

pgsql-patches by date

Next:From: davegDate: 2007-08-04 21:09:58
Subject: Re: Repair cosmetic damage (done by pg_indent?)
Previous:From: Tom LaneDate: 2007-08-04 19:55:57
Subject: Re: Repair cosmetic damage (done by pg_indent?)

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