Re: Internal fragmentations statistics Was: VACUUM FULL memory requirements

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: pgsql-admin(at)postgresql(dot)org
Cc: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Evan Rempel <erempel(at)uvic(dot)ca>
Subject: Re: Internal fragmentations statistics Was: VACUUM FULL memory requirements
Date: 2009-12-16 07:51:44
Message-ID: 200912160851.44891.guillaume@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Le mercredi 16 décembre 2009 à 06:18:45, Gurjeet Singh a écrit :
> 2009/12/15 Guillaume Lelarge <guillaume(at)lelarge(dot)info>
>
> > Le mardi 15 décembre 2009 à 00:04:47, Evan Rempel a écrit :
> > > Is there a command/tool that will report on how FULL a table is
> > > getting? If there is, how intrusive is it? How computationally heavy is
> > > it?
> > >
> > > We have a database that is approx 100 million rows with
> > > approx 2 million insert/updates per day. Each day old data
> > > is purged from the database. The end result is a mostly static
> > > footprint with regards to disk space used, but I would like to
> > > know how much room is usable inside the tables as well as the
> > > OS file system (that part is easy).
> >
> > pgstattuple contrib module give such an information. But it requires an
> > exclusive lock on the table it's looking at, so it's quite intrusive. For
> > more
> > details, the 8.4 documentation is interesting:
> > http://www.postgresql.org/docs/8.4/interactive/pgstattuple.html
>
> That doc specifically says that it takes only a read lock.
>

Ouch, I always thought it took an exclusive lock. Sorry.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Su, Alan 2009-12-16 13:19:38 Re: Looking for Good and Easy-to-use Reporting Tool
Previous Message Brian Modra 2009-12-16 07:43:46 Re: Looking for Good and Easy-to-use Reporting Tool