Re: display previous query string of idle-in-transaction

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: display previous query string of idle-in-transaction
Дата
Msg-id 27627.1248448500@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: display previous query string of idle-in-transaction  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: display previous query string of idle-in-transaction  (Robert Haas <robertmhaas@gmail.com>)
Re: display previous query string of idle-in-transaction  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: display previous query string of idle-in-transaction
Следующее
От: mahendra chavan
Дата:
Сообщение: Re: query decorrelation in postgres