Re: display previous query string of idle-in-transaction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: display previous query string of idle-in-transaction
Date
Msg-id 27627.1248448500@sss.pgh.pa.us
Whole thread Raw
In response to Re: display previous query string of idle-in-transaction  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: display previous query string of idle-in-transaction
Re: display previous query string of idle-in-transaction
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Hmm, I don't think we'd need two columns for this, actually.  You
> could just have one column last_statement_endtime (not sure if it's
> the best name, but something along those lines) which would be NULL if
> the statement was still in progress and the appropriate timestamp if
> not.  You could infer idle from whether or not that column was NULL.

Yeah, but "where idle" or "where not idle" is a lot easier to type.
I think the extra column is justified on usability grounds.  I'm also
not entirely convinced that we want last_statement_endtime, because
introducing that will cost us an extra kernel call per query in a lot of
scenarios.  And gettimeofday() is not cheap everywhere.

Another question is that this proposal effectively redefines the
current_query column as not the "current" query, but something that
might be better be described as "latest_query".  Should we change the
name?  We'd probably break some client code if we did, but on the other
hand the semantics change might break such code anyway.  Intentional
breakage might not be such a bad thing if it forces people to take a
fresh look at their code.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: display previous query string of idle-in-transaction
Next
From: mahendra chavan
Date:
Subject: Re: query decorrelation in postgres