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 34d269d40901012144v1c9f79c7vf4db432f764d7091@mail.gmail.com
Whole thread Raw
In response to Significantly larger toast tables on 8.4?  ("Alex Hunsaker" <badalex@gmail.com>)
Responses Re: Significantly larger toast tables on 8.4?  ("Alex Hunsaker" <badalex@gmail.com>)
List 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 by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: posix_fadvise v22
Next
From: David Fetter
Date:
Subject: Re: SQL/MED compatible connection manager