Re: Bloated Table

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.

In response to

Responses

Browse pgsql-general by date

  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