Re: psql \watch versus \timing - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: psql \watch versus \timing
Date
Msg-id CAB7nPqTcJFcAUbgYiggoBQ3n+u_0K8O35v92wPYssGB26baRMg@mail.gmail.com
Whole thread Raw
In response to Re: psql \watch versus \timing  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: psql \watch versus \timing
List pgsql-hackers
On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> Attached patch changes \watch so that it displays how long the query takes
>>> if \timing is enabled.
>>>
>>> I didn't refactor PSQLexec and SendQuery into one routine because
>>> the contents of those functions are not so same. I'm not sure how much
>>> it's worth doing that refactoring. Anyway this feature is quite useful
>>> even without that refactoring, I think.
>>
>> The patch applies correctly and it does correctly what it is made for:
>> =# \timing
>> Timing is on.
>> =# select 1;
>>  ?column?
>> ----------
>>         1
>> (1 row)
>> Time: 0.407 ms
>> =# \watch 1
>> Watch every 1s    Mon Aug 18 15:17:41 2014
>>  ?column?
>> ----------
>>         1
>> (1 row)
>> Time: 0.397 ms
>> Watch every 1s    Mon Aug 18 15:17:42 2014
>>  ?column?
>> ----------
>>         1
>> (1 row)
>> Time: 0.615 ms
>>
>> Refactoring it would be worth it thinking long-term... And printing
>> the timing in PSQLexec code path is already done in SendQuery, so
>> that's doing two times the same thing IMHO.
>>
>> Now, looking at the patch, introducing the new function
>> PSQLexecInternal with an additional parameter to control the timing is
>> correct choosing the non-refactoring way of doing. But I don't think
>> that printing the time outside PSQLexecInternal is consistent with
>> SendQuery. Why not simply control the timing with a boolean flag and
>> print the timing directly in PSQLexecInternal?
>
> Because the timing needs to be printed after the query result.
Thanks for pointing that. Yes this makes the refactoring a bit more difficult.
-- 
Michael



pgsql-hackers by date:

Previous
From: 土卜皿
Date:
Subject: how to understand these macro defines such as ObjectIdAttributeNumber in sysattr.h?
Next
From: Michael Paquier
Date:
Subject: Re: how to understand these macro defines such as ObjectIdAttributeNumber in sysattr.h?