Re: Use case for enabling log_duration other than benchmarking

On 1/10/23 09:57, Alicja Kucharczyk wrote:
> 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
> settinglog_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 your application /*requires*/ subsecond response, and you're only getting
subsecond response some of the time, then you obviously want to know why. 
Part of that is checking to see if the database and queries are doing their job.

> - 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?

--
Born in Arizona, moved to Babylonia.