Re: [BUGS] Rapid deteriation of performance (might be caused by tsearch?) in 7.3.2 - Mailing list pgsql-performance

From Robert John Shepherd
Subject Re: [BUGS] Rapid deteriation of performance (might be caused by tsearch?) in 7.3.2
Date
Msg-id 002801c2fd11$8f893340$f3b0313e@LAIKA
Whole thread Raw
In response to Re: [BUGS] Rapid deteriation of performance (might be  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List pgsql-performance
> > I've been running this daily:
> >     vacuumdb -h localhost -a -z
> > Should I be using the full switch then?
>
> Well, you generally shouldn't need to if the fsm settings are high
enough.
> If you're doing really big updates like update each row of a 1 billion
> row table, you may end up having to do one immediately following that.
> Of course, if you're doing that, performance is probably not your
biggest
> concern. ;)

Not doing that, no. ;)


> Explain analyze'll tell us if the system is changing plans (presumably
to
> a worse one)

It wasn't, oddly enough.

I've added a new table that cuts down 85% of the work this query has to
do, and it seems to have helped an awful lot at the moment. Of course
only time will tell. :)

Thanks for the suggestions.


Yours Unwhettedly,
Robert John Shepherd.

Editor
DVD REVIEWER
The UK's BIGGEST Online DVD Magazine
http://www.dvd.reviewer.co.uk

For a copy of my Public PGP key, email: pgp@robertsworld.org.uk


pgsql-performance by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: [SQL] can i make this sql query more efficiant?
Next
From: Howard Oblowitz
Date:
Subject: Load times on RAID0 compared to RAID5