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: (view raw, whole thread or download thread mbox)
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

In response to


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-2017 The PostgreSQL Global Development Group