Re: Repair cosmetic damage (done by pg_indent?)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Decibel!" <decibel(at)decibel(dot)org>
Cc: "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Repair cosmetic damage (done by pg_indent?)
Date: 2007-08-04 19:19:24
Message-ID: 87bqdnkszn.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Decibel!" <decibel(at)decibel(dot)org> writes:

> On Sun, Jul 29, 2007 at 12:06:50PM +0100, Gregory Stark wrote:
>> You would have to recompile with the value at line 214 of
>> src/backend/utils/adt/pg_lzcompress.c set to a lower value.
>
> Doesn't seem to be working for me, even in the case of a table with a
> bunch of rows containing nothing but 213 'x's. I can't do anything that
> changes what pg_class.relpages shows.

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.

Actually the toaster would stop compressing fields once the total was under
2k. Perhaps for a situation like that we might want some form of STORAGE
parameter which a) set a flag on the tuple descriptor which forced the toaster
to be invoked every time and b) forced every field which that STORAGE
parameter to be compressed even if the tuple fits in the 2k target size.

But all this depends on what we want to do with the toast target size. If we
can set a per-table toast target size then that situation could be dealt with
by adjusting that parameter.

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-08-04 19:55:57 Re: Repair cosmetic damage (done by pg_indent?)
Previous Message Decibel! 2007-08-04 17:24:51 Re: Repair cosmetic damage (done by pg_indent?)