>> I didn't noticed it. Could you give me the message id or URL? >> >> > https://commitfest.postgresql.org/10/634/ > > https://www.postgresql.org/message-id/flat/CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=b4dm...@mail.gmail.com#CAMsr+YFUjJytRyV4J-16bEoiZyH=4nj+sQ7JP9ajwz=b4dm...@mail.gmail.com
Thanks. >> Another issue is inconsistency with log duration, which shows the the >> elapsed time for each execute message. I think statement timeout >> should be consistent with statement duration. Otherwise users will be >> confused. >> > > While I agree that's confusing, I think that's actualyl a problem with > log_duration. > > log_duration is really more of an internal trace parameter that should be > named debug_log_duration or something IMO. It also fails to print the > message type, which makes it even more confusing since it for a typical > extended protocl query it usually logs 3 durations with no indication of > which is what. It's definitely a poor design. > Users should be using log_min_duration_statement. You know, the confusingly > named one. Or is it log_duration_min_statement or > log_statement_min_duration or ...? > > Yeah, log_duration is confusing to the point I think it needs a comment > like "To record query run-time you probably want > log_min_duration_statement, not log_duration". I'm confused. Regarding the timing whether duration is emitted at sync or each message, log_duration and log_min_duration_statement behave exactly same, no? If so, log_min_duration_statement is not consistent with statement_timeout, anyway. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
