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 по дате отправления: