Neil Conway <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> One trick is that these should be the same: >> test=> SELECT statement_timestamp(), transaction_timestamp();
> Should they be? ISTM that the most useful definition of "statement_timestamp" is really "time of arrival of the latest interactive command from the client", and as such it should not be tied to statement start per se at all. I'd be in favor of doing gettimeofday() upon receiving a client message, reporting that value directly for statement_timestamp, and copying it during transaction start to obtain the value to use for transaction_timestamp. I don't much like the idea of doing a gettimeofday() per SQL statement, especially not if that's taken to mean every SQL statement issued by PL functions (and if it doesn't mean that, "statement_timestamp" seems like the wrong name). One gettimeofday() per client message doesn't seem too horrible though, since that's certainly going to require at least a couple of kernel calls anyway. Possibly we should call it "command_timestamp" not "statement_timestamp" to help reduce confusion. The patch as given strikes me as pretty broken --- it does not advance statement_timestamp when I would expect (AFAICS it only sets it during transaction start). I don't like it stylistically either: ISTM either these things are the responsibility of xact.c or they are the responsibility of postgres.c, it is not sensible to have both modules assigning to statement_timestamp. BTW, now that I look at it, the "statement_timeout" GUC variable seems to have much of the same confusion about whether "statement" is equivalent to "interactive command" or not. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings