Hi, 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. I understand that vacuuming solves performance problems related to "holes" in data files created as a result of tables being updated. Do I understand correctly that if tables are dropped and recreated at the beginning of each test case, holes in data files are reclaimed, so there is no need for vacuuming from a performance perspective? I will double check whether the problematic test cases do indeed always drop their tables, but assuming they do, are there any factors in the database (apart from table updates) that can cause a linear slow-down with repetitive tasks? Thanks Peter -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin