Thread: psql \watch versus \timing
<div dir="ltr"><br /><div style="style">I'd like to run same query repeatedly and see how long it takes each time.</div><divstyle="style"><br /></div><div style="style">I thought \watch would be excellent for this, but it turns outthat using \watch suppresses the output of \timing.</div><div style="style"><br /></div><div style="style">Is this intentional,or unavoidable? </div><div style="style"><br /></div><div style="style">Also, is it just or does the inabilityto watch more frequently than once a second make it a lot less useful than it could be?</div><div style="style"><br/></div><div style="style"><br /></div><div style="style">Cheers,</div><div style="style"><br /></div><divstyle="style">Jeff</div></div>
Jeff Janes <jeff.janes@gmail.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@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.janes@gmail.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
Attachment
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? Regards, -- Michael
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. Regards, -- Fujii Masao
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
On 08/18/2014 10:51 AM, Michael Paquier wrote: > 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 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@vmware.com> wrote: > On 08/18/2014 10:51 AM, Michael Paquier wrote: >> >> 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 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@vmware.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@vmware.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@vmware.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@vmware.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
Attachment
On 08/28/2014 02:46 PM, Fujii Masao wrote: > On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas > <hlinnakangas@vmware.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@vmware.com> wrote: > On 08/28/2014 02:46 PM, Fujii Masao wrote: >> >> On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas >> <hlinnakangas@vmware.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.paquier@gmail.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@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.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
Attachment
On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier <michael.paquier@gmail.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@mit.edu> wrote: > On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier > <michael.paquier@gmail.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.fujii@gmail.com> wrote: > On Wed, Sep 3, 2014 at 10:56 PM, Greg Stark <stark@mit.edu> wrote: >> On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier >> <michael.paquier@gmail.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.fujii@gmail.com> wrote: > On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas > <hlinnakangas@vmware.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@vmware.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
Attachment
On Thu, Sep 4, 2014 at 1:44 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.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.fujii@gmail.com> wrote: > > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.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@momjian.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@momjian.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.fujii@gmail.com> wrote: >> > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.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.paquier@gmail.com> wrote: > On Tue, Oct 14, 2014 at 4:49 AM, Bruce Momjian <bruce@momjian.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.fujii@gmail.com> wrote: >>> > On Thu, Aug 28, 2014 at 8:46 PM, Fujii Masao <masao.fujii@gmail.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