From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | Ang Chin Han <angch(at)bytecraft(dot)com(dot)my>, Rhaoni Chiu Pereira <rhaoni(at)sistemica(dot)info>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Query too slow |
Date: | 2003-08-26 16:01:32 |
Message-ID: | 27125.1061913692@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Tue, 26 Aug 2003, Ang Chin Han wrote:
>> Veering aside a bit, since we usually pinpoint performance problems by
>> looking at EXPLAIN ANALYZE's differences between the planner's
>> estimation and actual execution's stats, what's involved in parsing the
>> EXPLAIN ANALYZE results, and highlighting the places where they are way
>> different? Bold, underline, or put some asterisks in front of those steps.
> The hardest part is determining where it matters I think. You can use the
> row counts as the base for that, but going from 1 row to 50 is not
> necessarily going to be an issue, but it might be if a nested loop is
> chosen.
We've been chatting about this idea among the Red Hat group. The RHDB
Visual Explain tool (get it at http://sources.redhat.com/rhdb/) already
computes the percent of total runtime represented by each plan node.
It seems like we could highlight nodes based on a large difference
between estimated and actual percentage, or just highlight the nodes
that are more than X percent of the runtime.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Johnson | 2003-08-26 17:11:41 | Re: [PERFORM] Best tweak for fast results.. ? |
Previous Message | Stephan Szabo | 2003-08-26 15:47:52 | Re: Query too slow |