From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Schöcke <asc(at)turtle-entertainment(dot)de>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Bloated Table |
Date: | 2009-05-27 18:10:37 |
Message-ID: | 20090527181037.GY32650@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Brad Nicholson wrote:
> On Wed, 2009-05-27 at 11:15 -0400, Tom Lane wrote:
> > =?iso-8859-1?Q?Alexander_Sch=F6cke?= <asc(at)turtle-entertainment(dot)de> writes:
> > > I'm using a view
> > > (http://pgsql.tapoueh.org/site/html/news/20080131.bloat.html) to
> > > display the bloat (unused disk space) of the tables in a PostgreSQL
> > > database.
> >
> > I wouldn't trust the calculations that view does in the least.
> > You might look at contrib/pgstattuple if you want numbers that
> > have some relationship to reality (and are correspondingly more
> > expensive to get :-()
>
> Is the referenced query reliable for even estimating, or is it flat our
> wrong?
>
> Co-workers that were PGCon are saying that this is becoming a
> popular/accepted way to check for bloated tables.
If "ma" is supposed to be "maxalign", then this code is broken because
it only reports mingw32 as 8, all others as 4, which is wrong.
However I think the big problem is that it relies on pg_class.relpages
and reltuples which are only accurate just after VACUUM, only a
sample-based estimate just after ANALYZE, and wrong at any other time
(assuming the table has any movement).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2009-05-27 18:25:40 | Re: Postgres Clustering |
Previous Message | Alan McKay | 2009-05-27 17:57:08 | Postgres Clustering |