Re: Relpages not being recovered?

From: "Adam Singer" <asinger(at)easyplanet(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Relpages not being recovered?
Date: 2002-09-05 16:56:16
Message-ID: EFDE174C81D5264AA89AB15AEC039A86025A85@epfr01.easyplanet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Actually, I thought a VACUUM or VACUUM ANALYZE would provide the results I wanted.

After I realized my error, a VACUUM FULL gave me what I needed and problem solved.

Thanks for the help though!

Adam

-----Message d'origine-----
De : Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Envoyé : jeudi 5 septembre 2002 18:47
À : Adam Singer
Cc : pgsql-admin(at)postgresql(dot)org
Objet : Re: [ADMIN] Relpages not being recovered?

"Adam Singer" <asinger(at)easyplanet(dot)com> writes:
> After deleting unecessary tuples, reindexing, and vacuuming, pg_class gives=
> the following:

Did you VACUUM FULL, or just VACUUM?

> Does anyone know what may be causing this and if there is a way to force th=
> e relpages column to be recalculated?

I can assure you that relpages is correct after a vacuum --- look at the
physical file for the table if you want to confirm it.

The answer you are probably really looking for is some combination of
more-frequent vacuums and increasing your FSM configuration parameters
so that free space in the table is recycled more effectively. Try
searching the list archives for "free space map".

regards, tom lane

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2002-09-05 17:01:02 Re: problems with InitDB under CyqWin
Previous Message Bruce Momjian 2002-09-05 16:49:41 Re: turn off auto-commit