| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Alex Hunsaker" <badalex(at)gmail(dot)com> |
| 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 01:30:30 |
| Message-ID: | 14969.1230946230@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Hunsaker | 2009-01-03 01:34:49 | Re: Hashtable entry recycling algorithm in pg_stat_statements |
| Previous Message | Tom Lane | 2009-01-03 01:23:52 | Re: Hashtable entry recycling algorithm in pg_stat_statements |