Re: Help tuning postgres

From: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Help tuning postgres
Date: 2005-10-12 22:00:36
Message-ID: 20051012220036.GE13571@phlogiston.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)crankycanuck(dot)ca
The whole tendency of modern prose is away from concreteness.
--George Orwell

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Csaba Nagy 2005-10-13 08:15:03 Re: Help tuning postgres
Previous Message Martin Nickel 2005-10-12 20:40:24 Sequential scan on FK join