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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: display previous query string of idle-in-transaction
Дата
Msg-id 603c8f070907240953i5be5557ah815b2f62dfb55c12@mail.gmail.com
обсуждение исходный текст
Ответ на Re: display previous query string of idle-in-transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jul 24, 2009 at 11:15 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> 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.

I hate redundancy, but I don't care enough to argue about it.

> 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.

+1 for intentional breakage.  I like the name, too.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Emanuel Calvo Franco
Дата:
Сообщение: uuid contrib don't compile in OpenSolaris
Следующее
От: Sam Mason
Дата:
Сообщение: Re: When is a record NULL?