> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers