From: A.M. <agentm@themactionfaction.com>
To: pgsql-performance@postgresql.org
Subject: Re: Some queries starting to hang
Date: Tue, 6 Jun 2006 11:21:15 -0400 (EDT)
Message-ID: <47764.216.41.12.254.1149607275.squirrel@webmail.webopticon.org> (raw)
In-Reply-To: <1149604741.2621.487.camel@localhost.localdomain>
References: <1149534308.3583.56.camel@bg002441.pro-unlimited.com>
<22706.1149538039@sss.pgh.pa.us>
<20060605203851.GB7071@phlogiston.dyndns.org>
<23915.1149541591@sss.pgh.pa.us>
<1149604741.2621.487.camel@localhost.localdomain>
Explain analyze could at least put an asterisk around actual time that
deviated by some factor from the estimated time.
On Tue, June 6, 2006 10:39 am, Simon Riggs wrote:
>
> This is a good example of a case where the inefficiency of EXPLAIN
> ANALYZE would be a contributory factor to it not actually being
> available for diagnosing a problem.
>
> Maybe we need something even more drastic than recent proposed changes
> to EXPLAIN ANALYZE?
>
> Perhaps we could annotate the query tree with individual limits. That
> way a node that was expecting to deal with 1 row would simply stop
> executing the EXPLAIN ANALYZE when it hit N times as many rows (default=no
> limit). That way, we would still be able to see a bad plan even without
> waiting for the whole query to execute - just stop at a point where the
> plan is far enough off track. That would give us what we need: pinpoint
> exactly which part of the plan is off-track and see how far off track it
> is. If the limits were configurable, we'd be able to opt for
> faster-but-less-accurate or slower-yet-100% accuracy behaviour. We
> wouldn't need to worry about timing overhead either then.
>
> e.g. EXPLAIN ANALYZE ERRLIMIT 10 SELECT ...
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: agentm@themactionfaction.com
Subject: Re: Some queries starting to hang
In-Reply-To: <47764.216.41.12.254.1149607275.squirrel@webmail.webopticon.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox