Re: Help tuning postgres - Mailing list pgsql-performance

From Andrew Sullivan
Subject Re: Help tuning postgres
Date
Msg-id 20051012220036.GE13571@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Help tuning postgres  (Csaba Nagy <nagy@ecircle-ag.com>)
Responses Re: Help tuning postgres
List pgsql-performance
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

pgsql-performance by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Help tuning postgres
Next
From: Csaba Nagy
Date:
Subject: Re: Help tuning postgres