Re: Repair cosmetic damage (done by pg_indent?)
От | Gregory Stark |
---|---|
Тема | Re: Repair cosmetic damage (done by pg_indent?) |
Дата | |
Msg-id | 87bqdnkszn.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Repair cosmetic damage (done by pg_indent?) (Decibel! <decibel@decibel.org>) |
Ответы |
Re: Repair cosmetic damage (done by pg_indent?)
|
Список | pgsql-patches |
"Decibel!" <decibel@decibel.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
В списке pgsql-patches по дате отправления: