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

From Kirk Wolak
Subject Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)
Date
Msg-id CACLU5mQKvCHUaCx_yooZJZ=Ud1Bddux48j7C2xF0cNQC8AqVQg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)  (Maciek Sakrejda <m.sakrejda@gmail.com>)
Responses Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)
Re: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)
List pgsql-hackers
Everyone,
  I love that my proposal for %T in the prompt, triggered some great conversations.

  This is not instead of that.  That lets me run a query and come back HOURS later, and know it finished before 7PM like it was supposed to!

  This feature is simple.  We forget to set \timing on...
We run a query, and we WONDER... how long did  that take.

  This, too, should be a trivial problem (the code will tell).

  I am proposing this to get feedback (I don't have a final design in mind, but I will start by reviewing when and how ROW_COUNT gets set, and what \timing reports).

  Next up, as I learn (and make mistakes), this toughens me up...

  I am not sure the name is right, but I would like to report it in the same (ms) units as \timing, since there is an implicit relationship in what they are doing.

  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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Next
From: Tomas Vondra
Date:
Subject: Re: Add LZ4 compression in pg_dump