Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql) - Mailing list pgsql-hackers

From Kirk Wolak
Subject Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)
Date
Msg-id CACLU5mTx5LnPAM_BvNhMt--nEHf9mwtCA33wKRS--Mmk-nxfxg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)  (Jim Jones <jim.jones@uni-muenster.de>)
List pgsql-hackers
On Fri, Feb 24, 2023 at 7:09 AM Jim Jones <jim.jones@uni-muenster.de> wrote:
On 23.02.23 20:55, Kirk Wolak wrote:
> Everyone,
... SQL_EXEC_TIME
>   I think like ROW_COUNT, it should not change because of internal
> commands.
> So, you guys +1 this thing, give additional comments.  When the
> feedback settles, I commit to making it happen.
>
> Thanks, Kirk
>
I can see it being pretty handy to check if a certain task involving two
different terminal windows was done in the right order. Basically to see
what went wrong, e.g. "did I really stop the master database before
promoting the replica?"

+1 !

Best, Jim

Jim, thanks, here is that patch for the %T option, but I think you did a +1 for the new psql variable :SQL_EXEC_TIME.
I realized my communication style needs to be cleaner, I caused that with the lead in.

I created this proposal because I felt it was an excellent suggestion, and I think it will be trivial to implement, although
it will involve a lot more testing...  MANY times, I have run a query that took a touch too long, and I was wondering how long EXACTLY did that take.  This makes it easy  \echo :SQL_EXEC_TIME  (Well, I think it will be SQL_EXEC_ELAPSED)

regards, kirk

 
Attachment

pgsql-hackers by date:

Previous
From: Kirk Wolak
Date:
Subject: Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)
Next
From: Michael Paquier
Date:
Subject: Re: verbose mode for pg_input_error_message?