Re: psql \watch versus \timing

I'd like to run same query repeatedly and see how long it takes each time.

I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.

Is this intentional, or unavoidable?

Also, is it just or does the inability to watch more frequently than once a
second make it a lot less useful than it could be?

Cheers,

Jeff

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> I'd like to run same query repeatedly and see how long it takes each time.
> I thought \watch would be excellent for this, but it turns out that using
> \watch suppresses the output of \timing.

> Is this intentional, or unavoidable?

\watch uses PSQLexec not SendQuery; the latter implements \timing which
I agree is arguably useful here, but also autocommit/auto-savepoint
behavior which probably isn't a good idea.

It might be a good idea to refactor those two routines into one routine
with some sort of bitmap flags argument to control the various add-on
behaviors, but that seems like not 9.3 material anymore.

> Also, is it just or does the inability to watch more frequently than once a
> second make it a lot less useful than it could be?

It did not seem that exciting to me. In particular, we've already found
out that \watch with zero delay is a pretty bad idea, so you'd have to
make a case for what smaller minimum to use if it's not to be 1 second.

regards, tom lane

On Mon, May 20, 2013 at 7:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> I'd like to run same query repeatedly and see how long it takes each time.
>> I thought \watch would be excellent for this, but it turns out that using
>> \watch suppresses the output of \timing.
>
>> Is this intentional, or unavoidable?
>
> \watch uses PSQLexec not SendQuery; the latter implements \timing which
> I agree is arguably useful here, but also autocommit/auto-savepoint
> behavior which probably isn't a good idea.
>
> It might be a good idea to refactor those two routines into one routine
> with some sort of bitmap flags argument to control the various add-on
> behaviors, but that seems like not 9.3 material anymore.

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.

BTW, I found that \watch doesn't check for async notifications. Is it useful
to allow \watch to do that? ISTM that it's not so bad idea to use \timing
to continuously check for async notifications. No?

Regards,

--
Fujii Masao

On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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?
Regards,
--
Michael

On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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.

Regards,

--
Fujii Masao

On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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

On 08/18/2014 10:51 AM, Michael Paquier wrote:
> On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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 reviewed this, so I'm marking this as Ready for Committer. Since
you're a committer yourself, I expect you'll take it over from here.

I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for
internal commands.

- Heikki

On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 08/18/2014 10:51 AM, Michael Paquier wrote:
>>
>> On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
>> wrote:
>>>
>>> On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
>>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>>>
>>>> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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 reviewed this, so I'm marking this as Ready for Committer. Since
> you're a committer yourself, I expect you'll take it over from here.

Yep!

> I agree that refactoring this would be nice in the long-term, and I also
> agree that it's probably OK as it is in the short-term. I don't like the
> name PSQLexecInternal, though. PSQLexec is used for "internal" commands
> anyway. In fact it's backwards, because PSQLexecInternal is used for
> non-internal queries, given by \watch, while PSQLexec is used for internal
> commands.

Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?

Regards,

--
Fujii Masao

On 08/25/2014 09:22 PM, Fujii Masao wrote:
> On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> I agree that refactoring this would be nice in the long-term, and I also
>> agree that it's probably OK as it is in the short-term. I don't like the
>> name PSQLexecInternal, though. PSQLexec is used for "internal" commands
>> anyway. In fact it's backwards, because PSQLexecInternal is used for
>> non-internal queries, given by \watch, while PSQLexec is used for internal
>> commands.
>
> Agreed. So what about PSQLexecCommon (inspired by
> the relation between LWLockAcquireCommon and LWLockAcquire)?
> Or any better name?

Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling. Do we want --echo-hidden to print the \watch'd
query? Not sure..

- Heikki

On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
> On 08/25/2014 09:22 PM, Fujii Masao wrote:
>> On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> I agree that refactoring this would be nice in the long-term, and I also
>>> agree that it's probably OK as it is in the short-term. I don't like the
>>> name PSQLexecInternal, though. PSQLexec is used for "internal" commands
>>> anyway. In fact it's backwards, because PSQLexecInternal is used for
>>> non-internal queries, given by \watch, while PSQLexec is used for internal
>>> commands.
>>
>> Agreed. So what about PSQLexecCommon (inspired by
>> the relation between LWLockAcquireCommon and LWLockAcquire)?
>> Or any better name?
>
> Actually, perhaps it would be better to just copy-paste PSQLexec, and
> modify the copy to suite \watch's needs. (PSQLexecWatch?
> SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
> overlap between what \watch wants and what other PSQLexec callers want.
> \watch wants timing output, others don't. \watch doesn't want
> transaction handling. Do we want --echo-hidden to print the \watch'd
> query? Not sure..

BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might
want to remove it, and replace with a comment noting that PSQLexec never
starts a new transaction block, even in autocommit-off mode. (I know
you're hacking on this, so I didnn't want to joggle your elbow by doing
it right now)

- Heikki

On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
>>
>> On 08/25/2014 09:22 PM, Fujii Masao wrote:
>>>
>>> On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
>>> <hlinnakangas(at)vmware(dot)com> wrote:
>>>>
>>>> I agree that refactoring this would be nice in the long-term, and I also
>>>> agree that it's probably OK as it is in the short-term. I don't like the
>>>> name PSQLexecInternal, though. PSQLexec is used for "internal" commands
>>>> anyway. In fact it's backwards, because PSQLexecInternal is used for
>>>> non-internal queries, given by \watch, while PSQLexec is used for
>>>> internal
>>>> commands.
>>>
>>>
>>> Agreed. So what about PSQLexecCommon (inspired by
>>> the relation between LWLockAcquireCommon and LWLockAcquire)?
>>> Or any better name?
>>
>>
>> Actually, perhaps it would be better to just copy-paste PSQLexec, and
>> modify the copy to suite \watch's needs. (PSQLexecWatch?
>> SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
>> overlap between what \watch wants and what other PSQLexec callers want.
>> \watch wants timing output, others don't. \watch doesn't want
>> transaction handling.

Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).

This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.

>> Do we want --echo-hidden to print the \watch'd
>> query? Not sure..

Per document, --echo-hidden prints the actual queries generated by
backslash command. But \watch doesn't handle backslash commands.
So I think that PSQLexecWatch doesn't need to handle --echo-hidden.

> BTW, I just noticed that none of the callers of PSQLexec pass
> "start_xact=true". So that part of the function is dead code. We might want
> to remove it, and replace with a comment noting that PSQLexec never starts a
> new transaction block, even in autocommit-off mode. (I know you're hacking
> on this, so I didnn't want to joggle your elbow by doing it right now)

Good catch. So I will remove start_xact code later.

Regards,

--
Fujii Masao

On 08/28/2014 02:46 PM, Fujii Masao wrote:
> On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
>>> Actually, perhaps it would be better to just copy-paste PSQLexec, and
>>> modify the copy to suite \watch's needs. (PSQLexecWatch?
>>> SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
>>> overlap between what \watch wants and what other PSQLexec callers want.
>>> \watch wants timing output, others don't. \watch doesn't want
>>> transaction handling.
>
> Agreed. Attached is the revised version of the patch. I implemented
> PSQLexecWatch() which sends the query, prints the results and outputs
> the query execution time (if \timing is enabled).
>
> This patch was marked as ready for committer, but since I revised
> the code very much, I marked this as needs review again.

This comment:

> ... We use PSQLexecWatch,
> ! * which is kind of cheating, but SendQuery doesn't let us suppress
> ! * autocommit behavior.

is a bit strange now. PSQLexecWatch isn't cheating like reusing PSQLexec
was; it's whole purpose is to run \watch queries.

> /*
> * Set up cancellation of 'watch' via SIGINT. We redo this each time
> * through the loop since it's conceivable something inside PSQLexec
> * could change sigint_interrupt_jmp.
> */

This should now say "PSQLexecWatch".

Other than that, looks good to me.

- Heikki

On Fri, Aug 29, 2014 at 6:33 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 08/28/2014 02:46 PM, Fujii Masao wrote:
>>
>> On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>>
>>> On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
>>>>
>>>> Actually, perhaps it would be better to just copy-paste PSQLexec, and
>>>> modify the copy to suite \watch's needs. (PSQLexecWatch?
>>>> SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
>>>> overlap between what \watch wants and what other PSQLexec callers want.
>>>> \watch wants timing output, others don't. \watch doesn't want
>>>> transaction handling.
>>
>>
>> Agreed. Attached is the revised version of the patch. I implemented
>> PSQLexecWatch() which sends the query, prints the results and outputs
>> the query execution time (if \timing is enabled).
>>
>> This patch was marked as ready for committer, but since I revised
>> the code very much, I marked this as needs review again.
>
>
> This comment:
>
>> ... We use PSQLexecWatch,
>> ! * which is kind of cheating, but SendQuery doesn't let us
>> suppress
>> ! * autocommit behavior.
>
>
> is a bit strange now. PSQLexecWatch isn't cheating like reusing PSQLexec
> was; it's whole purpose is to run \watch queries.
>
>> /*
>> * Set up cancellation of 'watch' via SIGINT. We redo
>> this each time
>> * through the loop since it's conceivable something
>> inside PSQLexec
>> * could change sigint_interrupt_jmp.
>> */
>
>
> This should now say "PSQLexecWatch".
>
> Other than that, looks good to me.

I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?
--
Michael

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> I just tested the patch and this feature works as expected if timing
> is on and it displays the individual run time of each query kicked by
> \watch. Note that --echo-hidden does not display the query run during
> each loop and that this is contrary to the behavior in HEAD so it
> breaks backward compatibility, but are there really people relying in
> the existing behavior?

ISTM that's an anti-feature anyway, and changing that behavior is a
good thing.

regards, tom lane

On Mon, Sep 1, 2014 at 11:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> I just tested the patch and this feature works as expected if timing
>> is on and it displays the individual run time of each query kicked by
>> \watch. Note that --echo-hidden does not display the query run during
>> each loop and that this is contrary to the behavior in HEAD so it
>> breaks backward compatibility, but are there really people relying in
>> the existing behavior?
>
> ISTM that's an anti-feature anyway, and changing that behavior is a
> good thing.
OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.
This is ready for a committer.
Regards,
--
Michael

On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> OK, then as all the comments are basically addressed, here is an
> updated patch correcting the comment problems mentioned by Heikki.

I just tried this and found it doesn't cooperate well with AUTOCOMMIT
= 'off' and ON_ERROR_ROLLBACK = 'on'. Previously \watch would leave
the transaction in a normal state after C-c but now it leaves the
transaction in an aborted state. I assume it previously did a
savepoint around each execution and now it's not doing that at all.

--
greg

On Wed, Sep 3, 2014 at 10:56 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> OK, then as all the comments are basically addressed, here is an
>> updated patch correcting the comment problems mentioned by Heikki.

Thanks a lot!

> I just tried this and found it doesn't cooperate well with AUTOCOMMIT
> = 'off' and ON_ERROR_ROLLBACK = 'on'. Previously \watch would leave
> the transaction in a normal state after C-c but now it leaves the
> transaction in an aborted state. I assume it previously did a
> savepoint around each execution and now it's not doing that at all.

No. Previously \watch used PSQLexec and it doesn't use savepoint.
If you enter Ctrl-C while \watch is waiting for the query to end,
\watch would leave the transaction in an aborted state whether
the patch has been applied or not. OTOH, if you enter Ctrl-C while
\watch is sleeping, the transaction remains in normal state.

Regards,

--
Fujii Masao

On Wed, Sep 3, 2014 at 11:13 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Sep 3, 2014 at 10:56 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
>> On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> OK, then as all the comments are basically addressed, here is an
>>> updated patch correcting the comment problems mentioned by Heikki.
>
> Thanks a lot!

Applied. Thanks all!

Regards,

--
Fujii Masao

On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
>>>
>>> On 08/25/2014 09:22 PM, Fujii Masao wrote:
>>>>
>>>> On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
>>>> <hlinnakangas(at)vmware(dot)com> wrote:
>>>>>
>>>>> I agree that refactoring this would be nice in the long-term, and I also
>>>>> agree that it's probably OK as it is in the short-term. I don't like the
>>>>> name PSQLexecInternal, though. PSQLexec is used for "internal" commands
>>>>> anyway. In fact it's backwards, because PSQLexecInternal is used for
>>>>> non-internal queries, given by \watch, while PSQLexec is used for
>>>>> internal
>>>>> commands.
>>>>
>>>>
>>>> Agreed. So what about PSQLexecCommon (inspired by
>>>> the relation between LWLockAcquireCommon and LWLockAcquire)?
>>>> Or any better name?
>>>
>>>
>>> Actually, perhaps it would be better to just copy-paste PSQLexec, and
>>> modify the copy to suite \watch's needs. (PSQLexecWatch?
>>> SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
>>> overlap between what \watch wants and what other PSQLexec callers want.
>>> \watch wants timing output, others don't. \watch doesn't want
>>> transaction handling.
>
> Agreed. Attached is the revised version of the patch. I implemented
> PSQLexecWatch() which sends the query, prints the results and outputs
> the query execution time (if \timing is enabled).
>
> This patch was marked as ready for committer, but since I revised
> the code very much, I marked this as needs review again.
>
>>> Do we want --echo-hidden to print the \watch'd
>>> query? Not sure..
>
> Per document, --echo-hidden prints the actual queries generated by
> backslash command. But \watch doesn't handle backslash commands.
> So I think that PSQLexecWatch doesn't need to handle --echo-hidden.
>
>> BTW, I just noticed that none of the callers of PSQLexec pass
>> "start_xact=true". So that part of the function is dead code. We might want
>> to remove it, and replace with a comment noting that PSQLexec never starts a
>> new transaction block, even in autocommit-off mode. (I know you're hacking
>> on this, so I didnn't want to joggle your elbow by doing it right now)
>
> Good catch. So I will remove start_xact code later.

Attached patch removes start_xact from PSQLexec.

Regards,

--
Fujii Masao

On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Good catch. So I will remove start_xact code later.
> Attached patch removes start_xact from PSQLexec.
Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).
Regards,
--
Michael

On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
> On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >> Good catch. So I will remove start_xact code later.
> > Attached patch removes start_xact from PSQLexec.
> Nothing negative to say here :)
> Patch simply removes the second argument of PSQLexec that was set to
> the same value everywhere, aka false as noticed by Heikki. Comments
> and code blocks related to this parameter are removed, and the code
> compiles, passing check-world as well (just kicked the tests in case).

Uh, where are we on this? Should I commit it?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Tue, Oct 14, 2014 at 4:49 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
>> On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> >> Good catch. So I will remove start_xact code later.
>> > Attached patch removes start_xact from PSQLexec.
>> Nothing negative to say here :)
>> Patch simply removes the second argument of PSQLexec that was set to
>> the same value everywhere, aka false as noticed by Heikki. Comments
>> and code blocks related to this parameter are removed, and the code
>> compiles, passing check-world as well (just kicked the tests in case).
>
> Uh, where are we on this? Should I commit it?
The patch cleaning up the dead code of psql could be clearly applied
now. For the feature itself not sure, it may be better to let
Fujii-san manage it.
--
Michael

On Tue, Oct 14, 2014 at 8:11 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Oct 14, 2014 at 4:49 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> On Thu, Sep 4, 2014 at 10:50:58PM +0900, Michael Paquier wrote:
>>> On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> >> Good catch. So I will remove start_xact code later.
>>> > Attached patch removes start_xact from PSQLexec.
>>> Nothing negative to say here :)
>>> Patch simply removes the second argument of PSQLexec that was set to
>>> the same value everywhere, aka false as noticed by Heikki. Comments
>>> and code blocks related to this parameter are removed, and the code
>>> compiles, passing check-world as well (just kicked the tests in case).
>>
>> Uh, where are we on this? Should I commit it?
> The patch cleaning up the dead code of psql could be clearly applied
> now. For the feature itself not sure, it may be better to let
> Fujii-san manage it.

Applied.

Regards,

--
Fujii Masao