| From: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
|---|---|
| To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Identifying diskspace leakage |
| Date: | 2004-05-14 17:47:20 |
| Message-ID: | 1084556840.24051.7.camel@heat |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, 2004-05-14 at 10:10, Ed L. wrote:
> I am trying to identify tables with significant diskspace "leakage" due to
> in appropriately low max_fsm_pages settings. I can see the results of
> VACUUM ANALYZE VERBOSE output counts of tuples and unused tuples, and
> understand that (1 - (tuples/unused)) is the amount of diskspace available
> to be reclaimed with a VACUUM FULL or dump/reload.
>
> Is there a way to identify the numbers of unused tuples without performing a
> VACUUM? Is it stored in a system table anywhere? Other ideas on how to
> identify disk bloat short of forcing downtime?
You can calculate the number of bytes per row, multiply by the number of
live tuples (count(1) from table), and subtract that from the actual #
of bytes in the on-disk representation. The difference is wasted space.
-jwb
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory S. Williamson | 2004-05-14 17:48:33 | Re: dbmirror |
| Previous Message | Oleg Bartunov | 2004-05-14 17:28:18 | new version of tsearch2 introduction is available |