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

From: "Robert John Shepherd" <robert(at)reviewer(dot)co(dot)uk>
To: "'Stephan Szabo'" <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [BUGS] Rapid deteriation of performance (might be caused by tsearch?) in 7.3.2
Date: 2003-04-07 14:25:38
Message-ID: 002801c2fd11$8f893340$f3b0313e@LAIKA
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs 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(at)robertsworld(dot)org(dot)uk

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michal Taborsky 2003-04-07 15:16:25 CREATE USER within function
Previous Message Mark Pether 2003-04-07 13:27:07 Re: Bug #933: Too many inserts crash server

Browse pgsql-performance by date

  From Date Subject
Next Message Andrew Sullivan 2003-04-07 14:36:17 Re: Load times on RAID0 compared to RAID5
Previous Message Howard Oblowitz 2003-04-07 14:23:03 Load times on RAID0 compared to RAID5