Re: Database Optimization and Peformance

From: Ray Stell <stellr(at)cns(dot)vt(dot)edu>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Database Optimization and Peformance
Date: 2006-08-31 13:02:11
Message-ID: 20060831130211.GB29805@cns.vt.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, Aug 30, 2006 at 05:29:25PM -0400, Chris Browne wrote:
> joe(dot)mcclintock(at)antics(dot)com (Joe McClintock) writes:
> > My concern is this, doing a backup and restore does not seem an
> > appropriate way manage database fragmentation and performance. The
> > documentation I have read indicates that vacuum, analyze reindex are
> > the tools to use to de-fragment and optimize the database. In my
> > case they did not work and reindexing made query performance
> > slightly worse. Am I missing something? As the database grows, will
> > I need to essentially rebuild the db on a regular basis?

What data tells you that you have a fragmentation problem? Have you
baselined disk i/o? You appear to have determined how to fix the problem,
vacuum, based on what? I have a tool that looks like a hammer, therefore
the problem must be nails.

Reasonable DB performance tuning requires the ability to be able to
determine where the system is spending its time. Only then can a
reasonable solution be proposed. You are doing the opposite and
hoping to walk in the right door. We did this all through the 1990s with
oracle and it sucks. Not having methods of measuring what where the time
is being spent sucks and we will continue to feel suckage until we find
the tools that will show us what the system is doing that makes it "slow."

I'd love to hear wise pg people tell me what tools/methods are available
to provide response time data.

Again, thanks for all your help in my sharp pg learning curve.

> It oughtn't be necessary.
>
> It seems quite plausible that there are a few tables that are not
> being vacuumed nearly often enough.
>
> If you have tables where large portions are modified
> (updated/deleted), then you need to run VACUUM quite frequently,
> otherwise such tables will be overrun with dead space.
>
> We have tables that we run VACUUM on every five minutes because they
> change really heavily. (200-300 tuples, where we do an update to a
> tuple every time a customer is billed.)
> --
> "cbbrowne","@","ntlug.org"
> http://cbbrowne.com/info/finances.html
> Why does sour cream have an expiration date?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Markus Wollny 2006-08-31 13:41:51 Re: How to convert a string to bytea?
Previous Message RW 2006-08-31 08:25:44 Re: pg_dump: schema with OID 16396 does not exist