Skip site navigation (1) Skip section navigation (2)

Vacuuming static tables.

From: "Daniel T(dot) Staal" <DStaal(at)usa(dot)net>
To: pgsql-novice(at)postgresql(dot)org
Subject: Vacuuming static tables.
Date: 2006-05-10 15:48:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
I'm just trying to hunt down the reason for some odd behavior I'm noticing
here.  We vacuum our database once a week, which is good enough for most

However, there is one query that gets run interactively that slows down
considerably over the course of a week: One memorable week it was taking
over 15 seconds to run.  Just after a vacuum it takes around 0.7 seconds.

The odd thing is that while this is a moderately complex query; three
tables, multiple 'union's, etc, *all* the tables involved are fairly
static.  The biggest (and the one I've confirmed makes the difference when
I vacuum it) would be having a busy week if there were ten inserts. 
Deletes are even rarer.  Other tables in this database have several times
that traffic a minute.

So, I'm just wondering if there is a way to figure out why vacuuming that
table in particular makes such a difference.  It's not used that often,
but where it is used a person is waiting for the results.  (In contrast to
most of our database, which interacts with automated processes for the
most part.)

Of course, the solution is to vacuum it more often.  I'm just wondering
*why* it matters.  Any ideas on where to look?  We stay away from foreign
keys in this database...

Daniel T. Staal

This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.


pgsql-novice by date

Next:From: Sean DavisDate: 2006-05-10 15:49:46
Subject: Re: error handling
Previous:From: Sean DavisDate: 2006-05-10 15:23:36
Subject: Re: index not used with inherited tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group