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-03 02:27:46 |
Message-ID: | 34d269d40901021827w44ddd7dfw8814b25d71efbd2e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 2, 2009 at 18:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Alex Hunsaker" <badalex(at)gmail(dot)com> writes:
>> On Fri, Jan 2, 2009 at 11:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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",
>
>> And the toast file size is *drum roll* 167M.
>
> Hmmm ... so that's a lot closer to the original 145M, but it still
> seems like there's something else going on. It looks like the other
> thing we changed that might result in not compressing things was to
> increase the third entry (minimum compression rate) from 20% to 25%.
> Could you try it with that value also changed back?
With it back to 20% its now back to 145M.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-01-03 02:37:31 | Re: Significantly larger toast tables on 8.4? |
Previous Message | Tom Lane | 2009-01-03 01:46:21 | Re: Significantly larger toast tables on 8.4? |