Re: Some queries starting to hang

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Some queries starting to hang
Date: 2006-06-07 11:42:28
Message-ID: 1149680548.2621.600.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 2006-06-06 at 11:41 -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > On Tue, Jun 06, 2006 at 11:06:09AM -0400, Tom Lane wrote:
> >> I don't think that helps, as it just replaces one uncertainty by
> >> another: how far did the EXPLAIN really get towards completion of the
> >> plan? You still don't have any hard data.
>
> > Does that really matter, though? The point is to find the node where the
> > estimate proved to be fantasy.
>
> No, the point is to find out what reality is.

My point is knowing reality with less than 100% certainty is still very
frequently useful.

> Just knowing that the
> estimates are wrong doesn't really get you anywhere (we pretty much knew
> that before we even started looking at the EXPLAIN, eh?).

We were lucky enough to have two EXPLAINS that could be examined for
differences. Often, you have just one EXPLAIN and no idea which estimate
is incorrect, or whether they are all exactly correct. That is when an
EXPLAIN ANALYZE becomes essential - yet a *full* execution isn't
required in order to tell you what you need to know.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message soni de 2006-06-07 12:43:11 Regarding ALTER Command
Previous Message Ron Mayer 2006-06-06 23:27:16 Re: lowering priority automatically at connection