| From: | Kirk Wolak <wolakk(at)gmail(dot)com> |
|---|---|
| To: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
| Cc: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Subject: | Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql) |
| Date: | 2023-02-23 19:55:33 |
| Message-ID: | CACLU5mQKvCHUaCx_yooZJZ=Ud1Bddux48j7C2xF0cNQC8AqVQg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2023-02-23 20:21:39 | pgsql: Add LZ4 compression to pg_dump |
| Previous Message | Andres Freund | 2023-02-23 19:39:53 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |