From: | "Alex Hunsaker" <badalex(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Significantly larger toast tables on 8.4? |
Date: | 2009-01-02 19:50:34 |
Message-ID: | 34d269d40901021150o1cebe383wc7dd98da4806ecda@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 2, 2009 at 11:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-01-02 19:58:46 | Re: Documenting serializable vs snapshot isolation levels |
Previous Message | Alex Hunsaker | 2009-01-02 19:42:56 | Re: Significantly larger toast tables on 8.4? |