Re: Significantly larger toast tables on 8.4?
От | Alex Hunsaker |
---|---|
Тема | Re: Significantly larger toast tables on 8.4? |
Дата | |
Msg-id | 34d269d40901012144v1c9f79c7vf4db432f764d7091@mail.gmail.com обсуждение исходный текст |
Ответ на | Significantly larger toast tables on 8.4? ("Alex Hunsaker" <badalex@gmail.com>) |
Ответы |
Re: Significantly larger toast tables on 8.4?
|
Список | pgsql-hackers |
On Thu, Jan 1, 2009 at 21:30, Alex Hunsaker <badalex@gmail.com> wrote: > My hunch is its related to > http://git.postgresql.org/?p=postgresql.git;a=commit;h=3b6942b3f2fe733572c05a71cb2d12e5ece60cd > or for the CVS inclined > http::/archives.postgresql.org/pgsql-committers/2008-03/msg00121.php > > But if anything that looks like it should help reduce size... Looking at the patch we dont compress things > 1M anymore so I thought maybe I was hitting that. But no luck there are only 39 rows where the row size > 1M... With those 39 being about 22M each. Unless I calculated something wrong. Oh and CLUSTER and VACUUM dont seem to help. select count(1) from dies;count -------52010 select count(1) from ( select coalesce(pg_column_size(action), 0) + coalesce(pg_column_size(die_id), 0) + coalesce(pg_column_size(cparam),0) + coalesce(pg_column_size(date_created), 0) + coalesce(pg_column_size(db_profile),0) + coalesce(pg_column_size(debug), 0) + coalesce(pg_column_size(defunct),0) + coalesce(pg_column_size(env), 0) + coalesce(pg_column_size(login), 0) + coalesce(pg_column_size(msg), 0) + coalesce(pg_column_size(open_user_id), 0) + coalesce(pg_column_size(page_load_id),0) + coalesce(pg_column_size(session_id), 0) + coalesce(pg_column_size(state),0) + coalesce(pg_column_size(state_action), 0) + coalesce(pg_column_size(user_id),0) + coalesce(pg_column_size(whoops), 0) as row_size from dies ) as foo where foo.row_size> 1024*1024;count ------- 39 BTW is there a "cooler" way to do this?
В списке pgsql-hackers по дате отправления: