On Fri, 2006-12-15 at 10:57 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@xxxxxxx> writes: > > Am Freitag, 15. Dezember 2006 11:28 schrieb Simon Riggs: > >> Until we work out a better solution we can fix this in two ways: > >> > >> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ... > >> 2. enable_analyze_timer = off | on (default) (USERSET) > > > The second one is enough in my mind. > > I don't see any point in either one. If you're not going to collect > timing data then the only useful info EXPLAIN ANALYZE could provide is > knowledge of which rowcount estimates are badly off ... and to get that, > you have to wait for the query to finish, which may well be impractical > even without the gettimeofday overhead. On a different part of this thread, you say: On Fri, 2006-12-15 at 09:56 -0500, Tom Lane wrote: > The fundamental problem with it was the assumption that different > executions of a plan node will have the same timing. That's not true, > in fact not even approximately true. It doesn't make sense to me to claim that the timing is so important that we cannot do without it, at the same time as saying it isn't even approximately true that is highly variable. > We had discussed upthread the > idea of having an option to issue a NOTICE as soon as any actual > rowcount exceeds the estimate by some-configurable-percentage, and that > seems to me to be a much more useful response to the problem of > "E.A. takes too long" than removing gettimeofday. > One thing that's not too clear to me though is how the NOTICE would > identify the node at which the rowcount was exceeded... We'd have to output the whole EXPLAIN as a NOTICE for it to make any sense. If we can't do without the timings, then half an EXPLAIN would be even worse. We'd need to take account of non-linear nodes. Hash nodes react badly beyond a certain point, HashAgg even worse. Sort performs poorly after the end of memory, as does Materialize. Other nodes are more linear so would need a different percentage. I don't like the sound of a whole gaggle of GUCs to describe that. Any ideas? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
