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

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

In response to

Browse pgsql-admin by date

  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