Date: Wed, 12 Oct 2005 18:00:36 -0400
From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Help tuning postgres
Message-ID: <20051012220036.GE13571@phlogiston.dyndns.org>
References: <1129128315.2995.174.camel@coppola.muc.ecircle.de>
	<f3c0b4080510120939x6c08feebvfad37c98df306538@mail.gmail.com>
	<1129136130.2995.188.camel@coppola.muc.ecircle.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1129136130.2995.188.camel@coppola.muc.ecircle.de>
User-Agent: Mutt/1.5.9i

On Wed, Oct 12, 2005 at 06:55:30PM +0200, Csaba Nagy wrote:
> Ok, that was the first thing I've done, checking out the explain of the
> query. I don't really need the analyze part, as the plan is going for
> the index, which is the right decision. The updates are simple one-row

How do you know?  You _do_ need the ANALYSE, because it'll tell you
what the query _actually did_ as opposed to what the planner thought
it was going to do.  

Note that EXPLAIN ANALYSE actually performs the work, so you better
do it in a transaction and ROLLBACK if it's a production system.

> Actually I've done an iostat run in the meantime (just learned how to
> use it), and looks like the disk is 100 saturated. So it clearly is a
> disk issue in this case. And it turns out the Oracle hardware has an

Yes, but it could be a disk issue because you're doing more work than
you need to.  If your UPDATEs are chasing down a lot of dead tuples,
for instance, you'll peg your I/O even though you ought to have I/O
to burn.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
The whole tendency of modern prose is away from concreteness.
		--George Orwell