Re: Slow after VACUUM, fast after DROP-CREATE INDEX - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Slow after VACUUM, fast after DROP-CREATE INDEX
Date
Msg-id 1091816272.27166.217.camel@localhost.localdomain
Whole thread Raw
In response to Re: Slow after VACUUM, fast after DROP-CREATE INDEX  (ruben <ruben20@superguai.com>)
Responses Re: Slow after VACUUM, fast after DROP-CREATE INDEX  (Gaetano Mendola <mendola@bigfoot.com>)
List pgsql-general
Unfortunately, the administrative overhead in 7.1.3 is noticeably higher
than it is in 7.4.  The overhead should be lowered even more in 8.0 with
the integration of the autovacuum daemon into the backend process.

On Fri, 2004-08-06 at 10:24, ruben wrote:
> Thanks Harald, i'm running PostgreSQL 7.1.3.
>
>
>
> Harald Fuchs wrote:
>
> > In article <411296B5.6000204@superguai.com>,
> > ruben <ruben20@superguai.com> writes:
> >
> >
> >>Today, one of the processes running daily took 4 hours when it takes
> >>about 5 minutes. After a VACCUM ANALYZE of the affected tables it took
> >>the same to finish, then I recreated (drop and create) the index of
> >>the affected table and the process when again fast. My question is,
> >>isn't enough to run a VACCUM to optimize a table and its indexes? Is
> >>it advisable to recreate indexes from time to time?
> >
> >
> > This was necessary in PostgreSQL up to 7.3.x, but 7.4.x is supposed to
> > fix that.  What version are you running?
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 7: don't forget to increase your free space map settings
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html
>


pgsql-general by date:

Previous
From: Oscar Tuscon
Date:
Subject: Re: Sequence Question DOH!
Next
From: "Scott Marlowe"
Date:
Subject: Re: Creating blank records with sequential record numbers