Re: Significantly larger toast tables on 8.4? - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: Significantly larger toast tables on 8.4?
Date
Msg-id 34d269d40901021150o1cebe383wc7dd98da4806ecda@mail.gmail.com
Whole thread Raw
In response to Re: Significantly larger toast tables on 8.4?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Significantly larger toast tables on 8.4?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 2, 2009 at 11:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Robert Haas" <robertmhaas@gmail.com> writes:
>> I've seen gzip approach 10X on what was basically a large
>> tab-separated values file, but I agree that some more experimentation
>> to determine the real cause of the problem would be useful.
>
> If I'm counting on my fingers correctly, you'd need to assume about
> 23X compression to get the reported size change...
>
> An easy way to prove or disprove the point would be to go into
> src/backend/utils/adt/pg_lzcompress.c, and change the second entry
> in strategy_default_data from "1024 * 1024" to "INT_MAX", then
> re-load the table with the modified backend (or you could even
> just do "CREATE TABLE foo AS SELECT * FROM existing_table" and
> then compare sizes).  If that puts the toast table size back where
> it had been, then Alex correctly diagnosed the cause.

And the toast file size is *drum roll* 167M.


pgsql-hackers by date:

Previous
From: "Alex Hunsaker"
Date:
Subject: Re: Significantly larger toast tables on 8.4?
Next
From: "Robert Haas"
Date:
Subject: Re: Documenting serializable vs snapshot isolation levels