Skip site navigation (1) Skip section navigation (2)

Re: Do we need vacuuming when tables are regularly dropped?

From: "Peter Kovacs" <maxottovonstirlitz(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Do we need vacuuming when tables are regularly dropped?
Date: 2008-09-29 12:33:32
Message-ID: b6e8f2e80809290533g2a7e09b1i110bb085ad75092e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Mon, Sep 29, 2008 at 2:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Peter Kovacs" <maxottovonstirlitz(at)gmail(dot)com> writes:
>> We have a number of automated performance tests (to test our own code)
>> involving PostgreSQL. Test cases are supposed to drop and recreate
>> tables each time they run.
>
>> The problem is that some of the tests show a linear performance
>> degradation overtime. (We have data for three months back in the
>> past.) We have established that some element(s) of our test
>> environment must be the culprit for the degradation. As rebooting the
>> test machine didn't revert speeds to baselines recorded three months
>> ago, we have turned our attention to the database as the only element
>> of the environment which is persistent across reboots. Recreating the
>> entire PGSQL cluster did cause speeds to revert to baselines.
>
> What it sounds like to me is that you're not vacuuming the system
> catalogs, which are getting bloated with dead rows about all those
> dropped tables.

Wow, great!

It is not immediately clear from the documentation, but the VACUUM
command also deals with the system catalogs as well, correct?

Thanks a lot!
Peter

>
>                        regards, tom lane
>

In response to

Responses

pgsql-admin by date

Next:From: Tom LaneDate: 2008-09-29 12:42:00
Subject: Re: Do we need vacuuming when tables are regularly dropped?
Previous:From: Tom LaneDate: 2008-09-29 12:16:23
Subject: Re: Do we need vacuuming when tables are regularly dropped?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group