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

Re: Vacuum goes worse

From: Stéphane Schildknecht <stephane(dot)schildknecht(at)postgresqlfr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Vacuum goes worse
Date: 2007-10-16 15:26:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Tom Lane a écrit :
> =?ISO-8859-1?Q?St=E9phane_Schildknecht?= <stephane(dot)schildknecht(at)postgresqlfr(dot)org> writes:
>> For some times, we have a vacuuming process on a specific table that
>> goes slower and slower. In fact, it took some 3 minutes a month ago, and
>> now it take almost 20 minutes. But, if one day it take so many time, it
>> is possible that on the day after it will only take 4 minutes...
>> I know the table in concern had 450000 tuples two months ago and now has
>> more than 700000 tuples in it.
> The real question is how often do rows get updated?  I suspect you
> probably need to vacuum this table more than once a day.

To be honest, I suspect it too. But, I have been told by people using
that database they can't do vacuum more frequently than once in a day as
it increases the time to achieve concurrent operations.
That's also why they don't want to hear about autovacuum.

And finally that's why I'm looking for everything I can monitor to
obtain information to convince them they're wrong and I'm right ;-)

That's also why I am so disappointed vacuum doesn't give me these 4
hints lines.


Président de PostgreSQLFr

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2007-10-16 15:30:31
Subject: Re: Vacuum goes worse
Previous:From: Heikki LinnakangasDate: 2007-10-16 15:22:48
Subject: Re: using a stored proc that returns a result set in a complex SQL stmt

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