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 > >
