| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Paul Lathrop <plathrop(at)squaretrade(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Defining performance. |
| Date: | 2006-12-01 00:26:36 |
| Message-ID: | 8312.1164932796@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Paul Lathrop <plathrop(at)squaretrade(dot)com> writes:
> ... When I joined the company last year, the databases were
> deployed on 12-disk RAID5 arrays on dual-proc AMD machines with 4Gb of
> RAM, running Debian Woody and Postgres 7.2. These systems seemed to
> suffer a gradually decreasing performance accompanied by a gradually
> growing disk space usage. The DBA had come to the conclusion that the
> VACUUM command did/does not work on these systems, because even after a
> VACUUM FULL, the size of the database was continually increasing.
The very first thing you need to do is get off 7.2.
After that, I'd recommend looking at *not* using VACUUM FULL. FULL is
actually counterproductive in a lot of scenarios, because it shrinks the
tables at the price of bloating the indexes. And 7.2's poor ability to
reuse index space turns that into a double whammy. Have you checked
into the relative sizes of tables and indexes and tracked the trend over
time?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | nospam | 2006-12-01 00:37:12 | Re: Defining performance. |
| Previous Message | Tobias Brox | 2006-12-01 00:05:37 | Re: Defining performance. |