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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-29 12:42:00 | Re: Do we need vacuuming when tables are regularly dropped? |
Previous Message | Tom Lane | 2008-09-29 12:16:23 | Re: Do we need vacuuming when tables are regularly dropped? |