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

Re: Where to start for performance problem?

From: "Nid" <mk_spam(at)comcast(dot)net>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Where to start for performance problem?
Date: 2003-11-25 03:05:56
Message-ID: 2b8e01c3b301$0bc2f090$0201a8c0@game (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I've been digging around in the code and found where we are executing the
VACUUM command.  VACUUM ANALYZE is executed every 15 minutes.  We haven't
tried VACUUM FULL ANALYZE.  I think I read that using FULL is a good idea
once a day or something.  Just doing a VACUUM ANALYZE doesn't seem to be
preventing our problem.  Thank you for the responses.


----- Original Message ----- 
From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "MK Spam" <mk_spam(at)comcast(dot)net>
Cc: <pgsql-performance(at)postgresql(dot)org>
Sent: Monday, November 24, 2003 7:13 PM
Subject: Re: [PERFORM] Where to start for performance problem?

> > The archives of this list provides many ideas for improving performance,
> > but the problem we are having is gradually degrading performance ending
> > in postgres shutting down.  So it's not a matter of optimizing a complex
> > query to take 5 seconds instead of 60 seconds.  >From what I can tell we
> > are using the VACUUM command on a schedule but it doesn't seem to
> > prevent the database from becoming "congested" as we refer to it.  :]
> Our busy website has a cronjob that runs VACUUM ANALYZE once an hour
> (vacuumdb -a -q -z).
> Have you tried going 'VACUUM FULL ANALYZE' (vacuumdb -a -q -z -f)
> instead of a dump and reload?
> Chris

In response to


pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2003-11-25 03:18:48
Subject: Re: Where to start for performance problem?
Previous:From: Neil ConwayDate: 2003-11-25 02:27:40
Subject: Re: VACUUM problems with 7.4

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