Re: Do we need vacuuming when tables are regularly dropped?
| От | Peter Kovacs |
|---|---|
| Тема | Re: Do we need vacuuming when tables are regularly dropped? |
| Дата | |
| Msg-id | b6e8f2e80809290533g2a7e09b1i110bb085ad75092e@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Do we need vacuuming when tables are regularly dropped? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Do we need vacuuming when tables are regularly dropped?
Re: Do we need vacuuming when tables are regularly dropped? |
| Список | pgsql-admin |
On Mon, Sep 29, 2008 at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Peter Kovacs" <maxottovonstirlitz@gmail.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 >
В списке pgsql-admin по дате отправления: