"NEVER" cautioned to auto_explain's log_analyze parameter on Production

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

"NEVER" cautioned to auto_explain's log_analyze parameter on Production

Jacque
I've seen it said to "NEVER" apply auto_explain's log_analyze parameter
on Production.    I get the general foreboding doom that can be beset by
a highly looping control structure eating up disk space (with no
indication of its exit condition time) but is genrous-disk-writes 
pretty much the only reason for avoiding this in folk's opinion?    And
say a well-mannered connection using it could be safe  in production?   
Seems to be afterall what the pganalyze folks must be  doing with their
commercial product afterall.



Reply | Threaded
Open this post in threaded view
|

Re: "NEVER" cautioned to auto_explain's log_analyze parameter on Production

Jeff Janes
On Wed, Feb 26, 2020 at 4:17 PM Jacque <[hidden email]> wrote:
I've seen it said to "NEVER" apply auto_explain's log_analyze parameter
on Production.    I get the general foreboding doom that can be beset by
a highly looping control structure eating up disk space (with no
indication of its exit condition time) but is genrous-disk-writes 
pretty much the only reason for avoiding this in folk's opinion?  

log_analyze doesn't take up dreadful amounts of disk space.  log_min_duration and sample_rate are how you control disk usage.

Some systems (combination of hardware and kernel) have slow clock access, and turning on log_anayze will greatly slow down your CPU-bound queries on such systems (I've seen as much as 10x slower), even the queries that end up not meeting log_min_duration.  If you are running a modern kernel on modern hardware, that probably isn't a problem.  It will still down queries by some amount, but probably not enough to matter, assuming the information it produces is valuable to you.

Cheers,

Jeff