Indexes and Tables: Growth and Treatment (Modified by Thomas F. O'Connell)

From: Thomas F(dot)O'Connell <tfo(at)sitening(dot)com>
To: Scott Holdren <scott(at)holdren(dot)com>
Subject: Indexes and Tables: Growth and Treatment (Modified by Thomas F. O'Connell)
Date: 2004-07-13 22:40:24
Message-ID: D90ECC10-D51F-11D8-A7DD-000D93AE0944@sitening.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I'm helping manage a postgres installation that continually consumes a
considerable amount of disk space, and I'm hoping to learn a bit more
about both treating the symptoms and addressing the causes.

Here are the basics:

It's a pg 7.4.1 installation on a Debian stable GNU/Linux 2.6.2 box
with 4GB RAM with 4 2.4 GHz processors and 36 GB of disk space.

There are thousands of tables, many of which are object-relational
(I.e., many are subclasses of sets of top-level tables). There are
indexes in place for joins that apply to many of the columns in the
subclassed tables.

It's a high turnover database, in that the applications that use it
perform thousands of inserts, updates, and deletes on a daily basis.

We're seeing about 5-10 GB of increased disk space used on a daily
basis if a vacuum (full) or reindexdb is not performed. We were doing
one vacuum analyze full a week with nightly vacuum analyzes. We began
manually reindexing the worst offenders once we passed 50% disk usage
regularly.

So here are my questions:

1. Is adding reindexdb to cron to reindex the entire database nightly
overkill?

2. If we turn on pg_autovacuum and leave in place one weekly vacuum
full, is that a reasonable strategy?

3. Otherwise, is it better in general to vacuum prior to reindexing?

4. What are the best places to look for causes of the velocity of
growth?

Thanks!

-tfo

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Carlos Roberto Chamorro Mostacilla 2004-07-13 23:47:36 Function and RowType
Previous Message Tom Lane 2004-07-13 21:55:50 Re: optimization with limit and order by in a view