> I am very surprised to find out that statement_timeout tracks the total > time and isn't reset by a new statement, but I guess it makes sense - what, > exactly, delimits a "query" in extended query mode? statement_timeout in > simple-query mode starts at parse time and runs until the end of execute. > In e.q.p. there might be only one parse, then a series of Bind and Execute > messages, or there may be repeated Parse messages.
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.
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".
