From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Kamen Stanev" <hambai(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: query io stats and finding a slow query |
Date: | 2007-09-21 16:35:15 |
Message-ID: | 46F3AC73.EE98.0025.0@wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>>> On Thu, Sep 20, 2007 at 4:36 PM, in message
<de5063670709201436y5cbff0d0k70ade289a4c68199(at)mail(dot)gmail(dot)com>, "Kamen Stanev"
<hambai(at)gmail(dot)com> wrote:
>
> Is there a way to find which query is doing large io operations and/or which
> is using cached data and which is reading from disk.
A big part of your cache is normally in the OS, which makes that tough.
> please share your experience on how do you decide which
> queries to optimize and how to reorganize your database?
We base this on two things -- query metrics from our application framework
and user complaints about performance.
> Is there any tools that you use to profile your database.
Many people set log_min_duration_statement to get a look at long-running
queries.
When you identify a problem query, running it with EXPLAIN ANALYZE in front
will show you the plan with estimated versus actual counts, costs, and time.
This does actually execute the query (unlike EXPLAIN without ANALYZE).
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-09-21 17:18:09 | Re: Searching for the cause of a bad plan |
Previous Message | Tom Lane | 2007-09-21 16:08:33 | Re: Searching for the cause of a bad plan |