From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Peter Kovacs" <maxottovonstirlitz(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Do we need vacuuming when tables are regularly dropped? |
Date: | 2008-09-29 12:16:23 |
Message-ID: | 9815.1222690583@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Kovacs | 2008-09-29 12:33:32 | Re: Do we need vacuuming when tables are regularly dropped? |
Previous Message | Sam Mason | 2008-09-29 11:26:34 | Re: PostgreSQL Cache |