Re: Use case for enabling log_duration other than benchmarking

wt., 10 sty 2023 o 14:57 Ron <ronljohnsonjr(at)gmail(dot)com> napisał(a):

> On 1/10/23 07:14, Alicja Kucharczyk wrote:
>
> Do you know any use case for enabling log_duration? Like 3rd party tools
> for instance.
> I find this parameter pretty much useless (in opposite to
> log_min_duration_statement) as it does not show the query text, so besides
> having just the timing logged it is of no use in troubleshooting and often
> causes huge overhead. Am I missing something?
>
>
> https://www.postgresql.org/docs/current/runtime-config-logging.html
>
> Note
>
> The difference between enabling log_duration and setting
> log_min_duration_statement
> <https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-MIN-DURATION-STATEMENT>
> to zero is that exceeding log_min_duration_statement forces the text of
> the query to be logged, but this option doesn't. Thus, if log_duration is
> on and log_min_duration_statement has a positive value, all durations are
> logged but the query text is included only for statements exceeding the
> threshold. *This behavior can be useful for gathering statistics in
> high-load installations.*
>

thank you Ron.
My question is a bit more practical - Does anyone really find it useful?
What value brings the info that 20% of my query are under 1ms and 10% over
1 minute - If just checked once and then turned off - I can understand to
have more visibility into the overall characteristics. But let say someone
have it enabled on a production system all the time - what could be the
reason for that?