pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feed"NEVER" cautioned to auto_explain's log_analyze parameter on Production
2+ messages / 2 participants
[nested] [flat]
* "NEVER" cautioned to auto_explain's log_analyze parameter on Production
@ 2020-02-26 21:17 Jacque <jacqueedmund@gmail.com>
2020-02-26 22:43 ` Re: "NEVER" cautioned to auto_explain's log_analyze parameter on Production Jeff Janes <jeff.janes@gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: Jacque @ 2020-02-26 21:17 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
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.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: "NEVER" cautioned to auto_explain's log_analyze parameter on Production
2020-02-26 21:17 "NEVER" cautioned to auto_explain's log_analyze parameter on Production Jacque <jacqueedmund@gmail.com>
@ 2020-02-26 22:43 ` Jeff Janes <jeff.janes@gmail.com>
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Janes @ 2020-02-26 22:43 UTC (permalink / raw)
To: Jacque <jacqueedmund@gmail.com>; +Cc: pgsql-admin@lists.postgresql.org
On Wed, Feb 26, 2020 at 4:17 PM Jacque <jacqueedmund@gmail.com> 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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2020-02-26 22:43 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 21:17 "NEVER" cautioned to auto_explain's log_analyze parameter on Production Jacque <jacqueedmund@gmail.com>
2020-02-26 22:43 ` Jeff Janes <jeff.janes@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox