From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Jacque <jacqueedmund(at)gmail(dot)com> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: "NEVER" cautioned to auto_explain's log_analyze parameter on Production |
Date: | 2020-02-26 22:43:53 |
Message-ID: | CAMkU=1ync6hzQgJJVZ5B3U2Y=MkZ29oMFBkteTOHbpzTc-G-Tg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, Feb 26, 2020 at 4:17 PM Jacque <jacqueedmund(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | manish yadav | 2020-02-27 04:22:06 | Re: pgbadger question |
Previous Message | Jacque | 2020-02-26 21:17:21 | "NEVER" cautioned to auto_explain's log_analyze parameter on Production |