Re: auto_explain WAS: RFC: Timing Events

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: auto_explain WAS: RFC: Timing Events
Date: 2012-11-08 19:16:55
Message-ID: 509C0527.6070105@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-08 19:17:59 Tweaking ResolveNew's API
Previous Message Alvaro Herrera 2012-11-08 19:06:47 Re: [BUG] False indication in pg_stat_replication.sync_state