> For the log volume, would it help if there was some "unexpectedness"
> threshold? That is, if a statement exceeds the duration threshold, it
> gets explained, But then it only gets logged if the actual duration
> divided by the cost estimate exceeds some threshold.
Thing is, pg_stat_plans makes this kind of use of auto_explain obsolete.With a much more useful interface.
Where autoexplain would be useful would be to get all of the plans,
regardless of execution time, for a specific application session or a
specific stored procedure. However, that requires the ability of the
application session to toggle auto-explain logging settings. This was
part of the functionality which Itagaki demonstrated for auto-explain
when he first proposed it, but was later disabled for security reasons
before commit IIRC. Writing a SECURITY DEFINER function to get around
inability to toggle as a regular user has been a nonstarter when I've
proposed it to clients.
Also, logging only the long-running queries is less useful than people
on this list seem to think. When I'm doing real performance analysis, I
need to see *everything* which was run, not just the slow stuff. Often
the real problem is a query which used to take 1.1ms, now takes 1.8ms,
and gets run 400 times/second. Looking just at the slow queries won't
tell you that.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
