Re: log_duration is redundant, no?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: log_duration is redundant, no?
Дата
Msg-id 7287.1158361194@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: log_duration is redundant, no?  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Ответы Re: log_duration is redundant, no?  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: log_duration is redundant, no?  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Список pgsql-hackers
"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> If we consider that the prepare and the bind operations are important
> (and I agree they can be), I wonder why do we remove the output we
> have when log_min_duration_statement is set to 0 (I'm thinking of the
> parse: and bind: lines)?

Well, we remove it for the execute: too if you have only log_duration
on.  My view of this is that log_duration is meant to find out the total
amount of time spent doing stuff, and you set log_min_duration_statement
to whatever your threshold of pain is for the amount of time spent doing
a single thing.  If it's less than log_min_duration_statement then
you're saying you don't care about the details of that individual step,
only the aggregate runtime.

log_statement has another goal entirely, which is to record *what* is
being done in a semantic sense, and so for that I think it makes sense
to log only actual executions (and not parse/bind leading up to 'em).

The only asymmetry in the thing is that if log_statement fired then
we suppress duplicate printing of the query in the later duration log
message (if any) for that query.  But that seems like the right thing
if you're at all concerned about log volume.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gevik Babakhani
Дата:
Сообщение: Re: question regarding regression tests
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Reducing data type space usage