Proposal: %T Prompt parameter for psql for current time (like Oracle has)
Proposal: Simply add the %T (PROMPT variable) to output the current time
(HH24:MI:SS) into the prompt. This has been in sqlplus since I can
remember, and I find it really useful when I forgot to time something, or
to review for Time spent on a problem, or for how old my session is...
I am recommending no formatting options, just keep it simple. No, I don't
care about adding the date. If I don't know the date of some line in my
history, it's already a problem! (And date would logically be some other
variable)
Yes, I've found ways around it using the shell backquote. This is hacky,
and it's also really ugly in windows. I also found it impossible to share
my plpgsqlrc file because between linux and windows.
This would be current time on the local machine. Keeping it simple.
It feels like a small change. The simplest test would be to capture the
prompt, select sleep(1.1); and make sure the prompt change. This code
should be trivially stable.
If it seems useful, I believe I can work with others to get it implemented,
and the documentation changed, and a patch generated. (I need to develop
these skills)
What does the community say? Is there support for this?
Regards, Kirk
On Wed, Feb 22, 2023 at 9:18 AM Kirk Wolak <wolakk@gmail.com> wrote:
Proposal: Simply add the %T (PROMPT variable) to output the current time
(HH24:MI:SS) into the prompt. This has been in sqlplus since I can
remember, and I find it really useful when I forgot to time something, or
to review for Time spent on a problem, or for how old my session is...
This is a great idea, in my opinion. I usually do something involving ts to
track timestamps when executing something non-trivial via psql in
interactive (see below) or non-interactive mode.
But this is a not well-known thing to use (and ts is not installed by
default on Ubuntu, etc.) – having timestamps in prompt would be convenient.
test=> \o | ts
test=> select 1;
test=> Feb 22 09:49:49 ?column?
Feb 22 09:49:49 ----------
Feb 22 09:49:49 1
Feb 22 09:49:49 (1 row)
Feb 22 09:49:49
Kirk Wolak <wolakk@gmail.com> writes:
Proposal: Simply add the %T (PROMPT variable) to output the current time
(HH24:MI:SS) into the prompt.
I'm not really convinced that %`date` isn't a usable solution for this,
especially since it seems like a very niche requirement. The next
person who wants it might well have a different desire than you
for exactly what gets shown. The output of date can be customized,
but a hard-wired prompt.c feature not so much.
On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.
regards, tom lane
On Wed, Feb 22, 2023 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.
It depends on personal preferences. When I work on a large screen, I can
afford to spend some characters in prompts, if it gives convenience – and
many do (looking, for example, at modern tmux/zsh prompts showing git
branch context, etc).
Default behavior might remain short – it wouldn't make sense to extend it
for everyone.
On 22/02/2023 19:59, Nikolay Samokhvalov wrote:
On Wed, Feb 22, 2023 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.It depends on personal preferences. When I work on a large screen, I can
afford to spend some characters in prompts, if it gives convenience –
and many do (looking, for example, at modern tmux/zsh prompts showing
git branch context, etc).Default behavior might remain short – it wouldn't make sense to extend
it for everyone.
I have no objections to adding a %T option, although deciding what
format to use is a hassle. -1 for changing the default.
But let's look at the original request:
This has been in sqlplus since I can remember, and I find it really
useful when I forgot to time something, or to review for Time spent
on a problem, or for how old my session is...
I've felt that pain too. You run a query, and it takes longer than I
expected. How long did it actually take? Too bad I didn't enable \timing
beforehand..
How about a new backslash command or psql variable to show how long the
previous statement took? Something like:
postgres=# select <unexpectedly slow query>
?column?
----------
123
(1 row)
postgres=# \time
Time: 14011.975 ms (00:14.012)
This would solve the "I forgot to time something" problem.
- Heikki
On 22 Feb 2023, at 19:14, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
How about a new backslash command or psql variable to show how long the previous statement took? Something like:
postgres=# select <unexpectedly slow query>
?column?
----------
123
(1 row)postgres=# \time
Time: 14011.975 ms (00:14.012)
This would solve the "I forgot to time something" problem.
I don't have an opinion on adding a prompt option, but I've wanted this
(without realizing this was the format of it) many times.
--
Daniel Gustafsson
Hi
st 22. 2. 2023 v 18:55 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Kirk Wolak <wolakk@gmail.com> writes:
Proposal: Simply add the %T (PROMPT variable) to output the current time
(HH24:MI:SS) into the prompt.I'm not really convinced that %`date` isn't a usable solution for this,
especially since it seems like a very niche requirement. The next
person who wants it might well have a different desire than you
for exactly what gets shown. The output of date can be customized,
but a hard-wired prompt.c feature not so much.On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.
Can we introduce some special syntax that allows using words (and maybe
some params)?
Regards
Pavel
Show quoted text
regards, tom lane
st 22. 2. 2023 v 19:14 odesílatel Heikki Linnakangas <hlinnaka@iki.fi>
napsal:
On 22/02/2023 19:59, Nikolay Samokhvalov wrote:
On Wed, Feb 22, 2023 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.It depends on personal preferences. When I work on a large screen, I can
afford to spend some characters in prompts, if it gives convenience –
and many do (looking, for example, at modern tmux/zsh prompts showing
git branch context, etc).Default behavior might remain short – it wouldn't make sense to extend
it for everyone.I have no objections to adding a %T option, although deciding what
format to use is a hassle. -1 for changing the default.But let's look at the original request:
This has been in sqlplus since I can remember, and I find it really
useful when I forgot to time something, or to review for Time spent
on a problem, or for how old my session is...I've felt that pain too. You run a query, and it takes longer than I
expected. How long did it actually take? Too bad I didn't enable \timing
beforehand..How about a new backslash command or psql variable to show how long the
previous statement took? Something like:postgres=# select <unexpectedly slow query>
?column?
----------
123
(1 row)postgres=# \time
Time: 14011.975 ms (00:14.012)
This would solve the "I forgot to time something" problem.
It is a good idea, unfortunately, it doesn't help with more commands. But
it is a nice idea, and can be implemented.
I am not sure if \time is best way - maybe we can display another runtime
data (when it will be possible, like io profile or queryid)
Regards
Pavel
Show quoted text
- Heikki
On Wed, Feb 22, 2023 at 12:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kirk Wolak <wolakk@gmail.com> writes:
Proposal: Simply add the %T (PROMPT variable) to output the current time
(HH24:MI:SS) into the prompt.I'm not really convinced that %`date` isn't a usable solution for this,
especially since it seems like a very niche requirement. The next
person who wants it might well have a different desire than you
for exactly what gets shown. The output of date can be customized,
but a hard-wired prompt.c feature not so much.On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.regards, tom lane
Tom,
I totally respect where you are coming from, and you are rightfully the
big dog!
In reverse order. That limited namespace. I assume you mean the 52 alpha
characters, of which, we are using 7,
and this change would make it 8. Can we agree that at the current pace of
consumption it will be decades before
we get to 26, and they appear to be pretty well defended?
I already requested ONLY the HH24 format. 8 characters of output. no
options. It's a waste of time.
After all these years, sqlplus still has only one setting (show it, or
not). I am asking the same here.
And I will gladly defend not changing it! Ever!
I believe that leaves the real question:
Can't we just shell out? (which is what I do no, with issues as stated, and
a lot harder to do from memory if someplace new)
It's far easier in linux than windows to get what you want.
It's much more complicated if you try to use the same pgsqlrc file for
multiple environments and users.
We are talking about adding this much code, and consuming 1 of the
remaining 45 namespace items.
case 'T':
time_t current_time = time(NULL);
struct tm *tm_info = localtime(¤t_time);
sprintf(buf, "%02d:%02d:%02d", tm_info->tm_hour,
tm_info->tm_min, tm_info->tm_sec);
break;
Does this help my case at all?
If I crossed any lines, it's not my intention. I was tired of dealing with
this, and helping others to set it up.
With Respect,
Kirk
On Wed, Feb 22, 2023 at 1:14 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 22/02/2023 19:59, Nikolay Samokhvalov wrote:
On Wed, Feb 22, 2023 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.It depends on personal preferences. When I work on a large screen, I can
afford to spend some characters in prompts, if it gives convenience –
and many do (looking, for example, at modern tmux/zsh prompts showing
git branch context, etc).Default behavior might remain short – it wouldn't make sense to extend
it for everyone.I have no objections to adding a %T option, although deciding what
format to use is a hassle. -1 for changing the default.But let's look at the original request:
This has been in sqlplus since I can remember, and I find it really
useful when I forgot to time something, or to review for Time spent
on a problem, or for how old my session is...I've felt that pain too. You run a query, and it takes longer than I
expected. How long did it actually take? Too bad I didn't enable \timing
beforehand..How about a new backslash command or psql variable to show how long the
previous statement took? Something like:postgres=# select <unexpectedly slow query>
?column?
----------
123
(1 row)postgres=# \time
Time: 14011.975 ms (00:14.012)
This would solve the "I forgot to time something" problem.
- Heikki
TBH, I have that turned on by default. Load a script. Have 300 of those
lines, and tell me how long it took?
In my case, it's much easier. The other uses cases, including noticing I
changed some configuration and I
should reconnect (because I use multiple sessions, and I am in the early
stages with lots of changes).
st 22. 2. 2023 v 18:59 odesílatel Nikolay Samokhvalov <samokhvalov@gmail.com>
napsal:
On Wed, Feb 22, 2023 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
On the whole I'd rather not eat more of the limited namespace for
psql prompt codes for this.It depends on personal preferences. When I work on a large screen, I can
afford to spend some characters in prompts, if it gives convenience – and
many do (looking, for example, at modern tmux/zsh prompts showing git
branch context, etc).Default behavior might remain short – it wouldn't make sense to extend it
for everyone.
+1
On Wed, Feb 22, 2023 at 07:17:37PM +0100, Daniel Gustafsson wrote:
On 22 Feb 2023, at 19:14, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
How about a new backslash command or psql variable to show how long the previous statement took? Something like:
postgres=# select <unexpectedly slow query>
?column?
----------
123
(1 row)postgres=# \time
Time: 14011.975 ms (00:14.012)
This would solve the "I forgot to time something" problem.
I don't have an opinion on adding a prompt option, but I've wanted this
(without realizing this was the format of it) many times.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 22.02.23 19:14, Heikki Linnakangas wrote:
How about a new backslash command or psql variable to show how long the
previous statement took? Something like:
If you don't have \timing turned on before the query starts, psql won't
record what the time was before the query, so you can't compute the run
time afterwards. This kind of feature would only work if you always
take the start time, even if \timing is turned off.
On 23/02/2023 13:20, Peter Eisentraut wrote:
On 22.02.23 19:14, Heikki Linnakangas wrote:
How about a new backslash command or psql variable to show how long the
previous statement took? Something like:If you don't have \timing turned on before the query starts, psql won't
record what the time was before the query, so you can't compute the run
time afterwards. This kind of feature would only work if you always
take the start time, even if \timing is turned off.
Correct. That seems acceptable though? gettimeofday() can be slow on
some platforms, but I doubt it's *that* slow, that we couldn't call it
two times per query.
- Heikki
Heikki Linnakangas <hlinnaka@iki.fi> writes:
On 23/02/2023 13:20, Peter Eisentraut wrote:
If you don't have \timing turned on before the query starts, psql won't
record what the time was before the query, so you can't compute the run
time afterwards. This kind of feature would only work if you always
take the start time, even if \timing is turned off.
Correct. That seems acceptable though? gettimeofday() can be slow on
some platforms, but I doubt it's *that* slow, that we couldn't call it
two times per query.
Yeah, you'd need to capture both the start and stop times even if
\timing isn't on, in case you get asked later. But the backend is
going to call gettimeofday at least once per query, likely more
depending on what features you use. And there are inherently
multiple kernel calls involved in sending a query and receiving
a response. I tend to agree with Heikki that this overhead would
be unnoticeable. (Of course, some investigation proving that
wouldn't be unwarranted.)
regards, tom lane
+1 on solving the general problem of "I forgot to set \timing--how
long did this run?". I could have used that more than once in the
past, and I'm sure it will come up again.
I think Heikki's solution is probably more practical since (1) even if
we add the prompt parameter originally proposed, I don't see it being
included in the default, so it would require users to change their
prompt before they can benefit from it and (2) even if we commit to
never allowing tweaks to the format, I foresee a slow but endless
trickle of requests and patches to do so.
Thanks,
Maciek
On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda <m.sakrejda@gmail.com>
wrote:
I think Heikki's solution is probably more practical since (1) ..
Note that these ideas target two *different* problems:
- what was the duration of the last query
- when was the last query executed
So, having both solved would be ideal.
On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov <samokhvalov@gmail.com>
wrote:
On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda <m.sakrejda@gmail.com>
wrote:I think Heikki's solution is probably more practical since (1) ..
Note that these ideas target two *different* problems:
- what was the duration of the last query
- when was the last query executedSo, having both solved would be ideal.
Fair point, but since the duration solution needs to capture two timestamps
anyway, it could print start time as well as duration.
The prompt timestamp could still be handy for more intricate session
forensics, but I don't know if that's a common-enough use case.
Thanks,
Maciek
Show quoted text
čt 23. 2. 2023 v 19:16 odesílatel Maciek Sakrejda <m.sakrejda@gmail.com>
napsal:
On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov <samokhvalov@gmail.com>
wrote:On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda <m.sakrejda@gmail.com>
wrote:I think Heikki's solution is probably more practical since (1) ..
Note that these ideas target two *different* problems:
- what was the duration of the last query
- when was the last query executedSo, having both solved would be ideal.
Fair point, but since the duration solution needs to capture two
timestamps anyway, it could print start time as well as duration.The prompt timestamp could still be handy for more intricate session
forensics, but I don't know if that's a common-enough use case.
It is hard to say what is a common enough case, but I cannot imagine more
things than this.
small notice - bash has special support for this
Regards
Pavel
Show quoted text
Thanks,
Maciek
On Thu, Feb 23, 2023 at 1:16 PM Maciek Sakrejda <m.sakrejda@gmail.com>
wrote:
On Thu, Feb 23, 2023, 09:55 Nikolay Samokhvalov <samokhvalov@gmail.com>
wrote:On Thu, Feb 23, 2023 at 9:05 AM Maciek Sakrejda <m.sakrejda@gmail.com>
wrote:I think Heikki's solution is probably more practical since (1) ..
Note that these ideas target two *different* problems:
- what was the duration of the last query
- when was the last query executedSo, having both solved would be ideal.
Fair point, but since the duration solution needs to capture two
timestamps anyway, it could print start time as well as duration.The prompt timestamp could still be handy for more intricate session
forensics, but I don't know if that's a common-enough use case.Thanks,
Maciek
It's really common during migrations, and forensics. I often do a bunch of
stuff in 2 systems. Then check the overlap.
Andrey brought up the value of 2 people separate working on things, being
able to go back and review when did you change that setting? Which has
happened to many of us in support sessions...
Thanks!
On Thu, Feb 23, 2023 at 9:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
On 23/02/2023 13:20, Peter Eisentraut wrote:
If you don't have \timing turned on before the query starts, psql won't
record what the time was before the query, so you can't compute the run
time afterwards. This kind of feature would only work if you always
take the start time, even if \timing is turned off.Correct. That seems acceptable though? gettimeofday() can be slow on
some platforms, but I doubt it's *that* slow, that we couldn't call it
two times per query.Yeah, you'd need to capture both the start and stop times even if
\timing isn't on, in case you get asked later. But the backend is
going to call gettimeofday at least once per query, likely more
depending on what features you use. And there are inherently
multiple kernel calls involved in sending a query and receiving
a response. I tend to agree with Heikki that this overhead would
be unnoticeable. (Of course, some investigation proving that
wouldn't be unwarranted.)regards, tom lane
Note, for this above feature, I was thinking we have a ROW_COUNT variable
I use \set to see.
The simplest way to add this is maybe a set variable: EXEC_TIME
And it's set when ROW_COUNT gets set.
+1
==
Now, since this opened a lively discussion, I am officially submitting my
first patch.
This includes the small change to prompt.c and the documentation. I had
help from Andrey Borodin,
and Pavel Stehule, who have supported me in how to propose, and use gitlab,
etc.
We are programmers... It's literally our job to sharpen our tools. And
PSQL is one of my most used.
A small frustration, felt regularly was the motive.
Regards, Kirk
PS: If I am supposed to edit the subject to say there is a patch here, I
did not know
PPS: I appreciate ANY and ALL feedback... This is how we learn!
Attachments:
psql-prompt-t.patchtext/plain; charset=US-ASCII; name=psql-prompt-t.patchDownload
From eaf6d05028052a3ccaa8d980953ac4fd75255250 Mon Sep 17 00:00:00 2001
From: Kirk Wolak <wolakk@gmail.com>
Date: Thu, 23 Feb 2023 17:52:09 +0000
Subject: [PATCH] Time option added to psql prompt
This adds a useful time option to the prompt: %T. Which does not
require a wasteful backquoted shell command which is also not
compatible between operating systems.
The format is simply HH24:MI:SS no other options available by design!
Author: Kirk Wolak <wolakk@gmail.com>
Reviewed-By: Andrey Borodin <amborodin@acm.org>
Reviewed-By: Nikolay Samokhvalov <samokhvalov@gmail.com>
Thread: https://postgr.es/m/CACLU5mSRwHr_8z%3DenMj-nXF1tmC7%2BJn5heZQNiKuLyxYUtL2fg%40mail.gmail.com
---
doc/src/sgml/ref/psql-ref.sgml | 9 +++++++++
src/bin/psql/prompt.c | 10 +++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index dc6528dc11d..04ab9eeb8c0 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -4575,6 +4575,15 @@ testdb=> <userinput>INSERT INTO my_table VALUES (:'content');</userinput>
</listitem>
</varlistentry>
+ <varlistentry id="app-psql-prompting-t-uc">
+ <term><literal>%T</literal></term>
+ <listitem>
+ <para>
+ The current time on the client in HH24:MI:SS format.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="app-psql-prompting-x">
<term><literal>%x</literal></term>
<listitem>
diff --git a/src/bin/psql/prompt.c b/src/bin/psql/prompt.c
index 969cd9908e5..a590c27389b 100644
--- a/src/bin/psql/prompt.c
+++ b/src/bin/psql/prompt.c
@@ -41,6 +41,7 @@
* or a ! if session is not connected to a database;
* in prompt2 -, *, ', or ";
* in prompt3 nothing
+ * %T - time in HH24:MI:SS format
* %x - transaction status: empty, *, !, ? (unknown or no connection)
* %l - The line number inside the current statement, starting from 1.
* %? - the error code of the last query (not yet implemented)
@@ -223,7 +224,14 @@ get_prompt(promptStatus_t status, ConditionalStack cstack)
break;
}
break;
-
+ /* output HH24:MI:SS */
+ case 'T':
+ {
+ time_t current_time = time(NULL);
+ struct tm *tm_info = localtime(¤t_time);
+ sprintf(buf, "%02d:%02d:%02d", tm_info->tm_hour, tm_info->tm_min, tm_info->tm_sec);
+ }
+ break;
case 'x':
if (!pset.db)
buf[0] = '?';
--
GitLabEveryone,
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
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak <wolakk@gmail.com> wrote:
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!
Neat! I have this info embedded in my Bash prompt [1]https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L278, but many a
times this is not sufficient to reconstruct the time it took to run
the shell command.
This feature is simple. We forget to set \timing on...
We run a query, and we WONDER... how long did that take.
And so I empathize with this need. I have set my Bash prompt to show
me this info [2]https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L262.This info is very helpful in situations where you
fire a command, get tired of waiting for it and walk away for a few
minutes. Upon return it's very useful to see exactly how long did it
take for the command to finish.
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.
+1
So, you guys +1 this thing, give additional comments. When the feedback settles, I commit to making it happen.
This is definitely a useful feature. I agree with everything in the
proposed UI (reporting in milliseconds, don't track internal commands'
timing).
I think 'duration' or 'elapsed' would be a better words in this
context. So perhaps the name could be one of :sql_exec_duration (sql
prefix feels superfluous), :exec_duration, :command_duration, or
:elapsed_time.
By using \timing, the user is explicitly opting into any overhead
caused by time-keeping. With this feature, the timing info will be
collected all the time. So do consider evaluating the performance
impact this can cause on people's workloads. They may not care for the
impact in interactive mode, but in automated scripts, even a moderate
performance overhead would be a deal-breaker.
[1]: https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L278
[2]: https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L262
Best regards,
Gurjeet
http://Gurje.et
On 23.02.23 20:55, Kirk Wolak wrote:
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...
I've been there many times!
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
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
On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh <gurjeet@singh.im> wrote:
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak <wolakk@gmail.com> wrote:
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!
Neat! I have this info embedded in my Bash prompt [1], but many a
times this is not sufficient to reconstruct the time it took to run
the shell command.
...I think like ROW_COUNT, it should not change because of internal
commands.
+1
So, you guys +1 this thing, give additional comments. When the feedback
settles, I commit to making it happen.
This is definitely a useful feature. I agree with everything in the
proposed UI (reporting in milliseconds, don't track internal commands'
timing).I think 'duration' or 'elapsed' would be a better words in this
context. So perhaps the name could be one of :sql_exec_duration (sql
prefix feels superfluous), :exec_duration, :command_duration, or
:elapsed_time.
I chose that prefix because it sorts near ROW_COUNT (LOL) when you do \SET
I agree that the name wasn't perfect...
I like SQL_EXEC_ELAPSED
keeping the result closer to ROW_COUNT, and it literally ONLY applies to SQL
By using \timing, the user is explicitly opting into any overhead
caused by time-keeping. With this feature, the timing info will be
collected all the time. So do consider evaluating the performance
impact this can cause on people's workloads. They may not care for the
impact in interactive mode, but in automated scripts, even a moderate
performance overhead would be a deal-breaker.
Excellent point. I run lots of long scripts, but I usually set \timing on,
just because I turn off everything else.
I tested 2,000+ lines of select 1; (Fast sql shouldn't matter, it's the
most impacted)
Honestly, it was imperceptible, Maybe approximating 0.01 seconds
With timing on: ~ seconds 0.28
With timing of: ~ seconds 0.27
The \timing incurs no realistic penalty at this point. The ONLY penalty we
could face is the time to
write it to the variable, and that cannot be tested until implemented. But
I will do that. And I will
report the results of the impact. But I do not expect a big impact. We
update SQL_COUNT without an issue.
And that might be much more expensive to get.
Thanks!
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
Attachments:
psql-prompt-t.patchtext/plain; charset=US-ASCII; name=psql-prompt-t.patchDownload
From eaf6d05028052a3ccaa8d980953ac4fd75255250 Mon Sep 17 00:00:00 2001
From: Kirk Wolak <wolakk@gmail.com>
Date: Thu, 23 Feb 2023 17:52:09 +0000
Subject: [PATCH] Time option added to psql prompt
This adds a useful time option to the prompt: %T. Which does not
require a wasteful backquoted shell command which is also not
compatible between operating systems.
The format is simply HH24:MI:SS no other options available by design!
Author: Kirk Wolak <wolakk@gmail.com>
Reviewed-By: Andrey Borodin <amborodin@acm.org>
Reviewed-By: Nikolay Samokhvalov <samokhvalov@gmail.com>
Thread: https://postgr.es/m/CACLU5mSRwHr_8z%3DenMj-nXF1tmC7%2BJn5heZQNiKuLyxYUtL2fg%40mail.gmail.com
---
doc/src/sgml/ref/psql-ref.sgml | 9 +++++++++
src/bin/psql/prompt.c | 10 +++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index dc6528dc11d..04ab9eeb8c0 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -4575,6 +4575,15 @@ testdb=> <userinput>INSERT INTO my_table VALUES (:'content');</userinput>
</listitem>
</varlistentry>
+ <varlistentry id="app-psql-prompting-t-uc">
+ <term><literal>%T</literal></term>
+ <listitem>
+ <para>
+ The current time on the client in HH24:MI:SS format.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="app-psql-prompting-x">
<term><literal>%x</literal></term>
<listitem>
diff --git a/src/bin/psql/prompt.c b/src/bin/psql/prompt.c
index 969cd9908e5..a590c27389b 100644
--- a/src/bin/psql/prompt.c
+++ b/src/bin/psql/prompt.c
@@ -41,6 +41,7 @@
* or a ! if session is not connected to a database;
* in prompt2 -, *, ', or ";
* in prompt3 nothing
+ * %T - time in HH24:MI:SS format
* %x - transaction status: empty, *, !, ? (unknown or no connection)
* %l - The line number inside the current statement, starting from 1.
* %? - the error code of the last query (not yet implemented)
@@ -223,7 +224,14 @@ get_prompt(promptStatus_t status, ConditionalStack cstack)
break;
}
break;
-
+ /* output HH24:MI:SS */
+ case 'T':
+ {
+ time_t current_time = time(NULL);
+ struct tm *tm_info = localtime(¤t_time);
+ sprintf(buf, "%02d:%02d:%02d", tm_info->tm_hour, tm_info->tm_min, tm_info->tm_sec);
+ }
+ break;
case 'x':
if (!pset.db)
buf[0] = '?';
--
GitLabOn Fri, Feb 24, 2023 at 10:56 PM Kirk Wolak <wolakk@gmail.com> wrote:
On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh <gurjeet@singh.im> wrote:
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak <wolakk@gmail.com> wrote:
...
I think like ROW_COUNT, it should not change because of internal
commands.
...By using \timing, the user is explicitly opting into any overhead
caused by time-keeping. With this feature, the timing info will be
collected all the time. So do consider evaluating the performance
impact this can cause on people's workloads. They may not care for the
impact in interactive mode, but in automated scripts, even a moderate
performance overhead would be a deal-breaker.Excellent point. I run lots of long scripts, but I usually set \timing
on, just because I turn off everything else.
I tested 2,000+ lines of select 1; (Fast sql shouldn't matter, it's the
most impacted)
Honestly, it was imperceptible, Maybe approximating 0.01 seconds
With timing on: ~ seconds 0.28
With timing of: ~ seconds 0.27The \timing incurs no realistic penalty at this point. The ONLY penalty
we could face is the time to
write it to the variable, and that cannot be tested until implemented.
But I will do that. And I will
report the results of the impact. But I do not expect a big impact. We
update SQL_COUNT without an issue.
And that might be much more expensive to get.
Okay, I've written and tested this using SQL_EXEC_ELAPSED (suggested name
improvement).
First, the instant you have ANY output, it swamps the impact. (I settled
on: SELECT 1 as v \gset xxx) for no output
Second, the variability of running even a constant script is mind-blowing.
Third, I've limited the output... I built this in layers (init.sql
initializes the psql variables I use), run_100.sql runs
another file (\i tst_2000.sql) 100 times. Resulting in 200k selects.
Executive Summary: 1,000,000 statements executed, consumes ~2 - 2.5
seconds of extra time (Total)
So, the per statement cost is: 2.5s / 1,000,000 = 0.000,0025 s per statement
Roughly: 2.5us
Unfortunately, my test lines look like this:
Without Timing
done 0.198215 (500) *total *98.862548 *min* 0.167614 *avg*
0.19772509600000000000 *max *0.290659
With Timing
done 0.191583 (500) *total* 100.729868 *min *0.163280 *avg
*0.20145973600000000000
*max *0.275787
Notice that the With Timing had a lower min, and a lower max. But a higher
average.
The distance between min - avg AND min - max, is big (those are for 1,000
selects each)
Are these numbers at the "So What" Level?
While testing, I got the distinct impression that I am measuring something
that changes, or that the
variance in the system itself really swamps this on a per statement basis.
It's only impact is felt
on millions of PSQL queries, and that's a couple of seconds...
Curious what others think before I take this any further.
regards, Kirk
Show quoted text
Thanks!
[1]:
https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L278
[2]:
https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L262Best regards,
Gurjeet
http://Gurje.et
po 27. 2. 2023 v 5:08 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
On Fri, Feb 24, 2023 at 10:56 PM Kirk Wolak <wolakk@gmail.com> wrote:
On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh <gurjeet@singh.im> wrote:
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak <wolakk@gmail.com> wrote:
...
I think like ROW_COUNT, it should not change because of internal
commands.
...By using \timing, the user is explicitly opting into any overhead
caused by time-keeping. With this feature, the timing info will be
collected all the time. So do consider evaluating the performance
impact this can cause on people's workloads. They may not care for the
impact in interactive mode, but in automated scripts, even a moderate
performance overhead would be a deal-breaker.Excellent point. I run lots of long scripts, but I usually set \timing
on, just because I turn off everything else.
I tested 2,000+ lines of select 1; (Fast sql shouldn't matter, it's the
most impacted)
Honestly, it was imperceptible, Maybe approximating 0.01 seconds
With timing on: ~ seconds 0.28
With timing of: ~ seconds 0.27The \timing incurs no realistic penalty at this point. The ONLY penalty
we could face is the time to
write it to the variable, and that cannot be tested until implemented.
But I will do that. And I will
report the results of the impact. But I do not expect a big impact. We
update SQL_COUNT without an issue.
And that might be much more expensive to get.Okay, I've written and tested this using SQL_EXEC_ELAPSED (suggested name
improvement).
First, the instant you have ANY output, it swamps the impact. (I settled
on: SELECT 1 as v \gset xxx) for no output
Second, the variability of running even a constant script is mind-blowing.
Third, I've limited the output... I built this in layers (init.sql
initializes the psql variables I use), run_100.sql runs
another file (\i tst_2000.sql) 100 times. Resulting in 200k selects.
This is the very worst case.
But nobody will run from psql 200K selects - can you try little bit more
real but still synthetic test case?
create table foo(a int);
begin
insert into foo values(1);
...
insert into foo values(200000);
commit;
Regards
Pavel
Show quoted text
Executive Summary: 1,000,000 statements executed, consumes ~2 - 2.5
seconds of extra time (Total)So, the per statement cost is: 2.5s / 1,000,000 = 0.000,0025 s per
statement
Roughly: 2.5usUnfortunately, my test lines look like this:
Without Timing
done 0.198215 (500) *total *98.862548 *min* 0.167614 *avg*
0.19772509600000000000 *max *0.290659With Timing
done 0.191583 (500) *total* 100.729868 *min *0.163280 *avg *0.20145973600000000000
*max *0.275787Notice that the With Timing had a lower min, and a lower max. But a
higher average.
The distance between min - avg AND min - max, is big (those are for 1,000
selects each)Are these numbers at the "So What" Level?
While testing, I got the distinct impression that I am measuring something
that changes, or that the
variance in the system itself really swamps this on a per statement
basis. It's only impact is felt
on millions of PSQL queries, and that's a couple of seconds...Curious what others think before I take this any further.
regards, Kirk
Thanks!
[1]:
https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L278
[2]:
https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L262Best regards,
Gurjeet
http://Gurje.et
On Sun, Feb 26, 2023 at 11:45 PM Pavel Stehule <pavel.stehule@gmail.com>
wrote:
po 27. 2. 2023 v 5:08 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
On Fri, Feb 24, 2023 at 10:56 PM Kirk Wolak <wolakk@gmail.com> wrote:
On Fri, Feb 24, 2023 at 2:11 AM Gurjeet Singh <gurjeet@singh.im> wrote:
On Thu, Feb 23, 2023 at 8:42 PM Kirk Wolak <wolakk@gmail.com> wrote:
...
...
Okay, I've written and tested this using SQL_EXEC_ELAPSED (suggested
name improvement).
First, the instant you have ANY output, it swamps the impact. (I settled
on: SELECT 1 as v \gset xxx) for no output
Second, the variability of running even a constant script is mind-blowing.
Third, I've limited the output... I built this in layers (init.sql
initializes the psql variables I use), run_100.sql runs
another file (\i tst_2000.sql) 100 times. Resulting in 200k selects.This is the very worst case.
But nobody will run from psql 200K selects - can you try little bit more
real but still synthetic test case?create table foo(a int);
begin
insert into foo values(1);
...
insert into foo values(200000);
commit;
*Without timing:*
postgres=# \i ins.sql
Elapsed Time: 29.518647 (seconds)
postgres=# \i ins.sql
Elapsed Time: 24.973943 (seconds)
postgres=# \i ins.sql
Elapsed Time: 21.916432 (seconds)
postgres=# \i ins.sql
Elapsed Time: 25.440978 (seconds)
postgres=# \i ins.sql
Elapsed Time: 24.848986 (seconds)
-- Because that was slower than expected, I exited, and tried again...
Getting really different results
postgres=# \i ins.sql
Elapsed Time: 17.763167 (seconds)
postgres=# \i ins.sql
Elapsed Time: 19.210436 (seconds)
postgres=# \i ins.sql
Elapsed Time: 19.903553 (seconds)
postgres=# \i ins.sql
Elapsed Time: 21.687750 (seconds)
postgres=# \i ins.sql
Elapsed Time: 19.046642 (seconds)
*With timing:*
\i ins.sql
Elapsed Time: 20.479442 (seconds)
postgres=# \i ins.sql
Elapsed Time: 21.493303 (seconds)
postgres=# \i ins.sql
Elapsed Time: 22.732409 (seconds)
postgres=# \i ins.sql
Elapsed Time: 20.246637 (seconds)
postgres=# \i ins.sql
Elapsed Time: 20.493607 (seconds)
Again, it's really hard to measure the difference as the impact, again, is
a bit below the variance.
In this case, I could see about a 1s - 2s (max) difference in total time.
for 200k statements.
Run 5 times (for 1 million).
It's a little worse than noise. But if I used the first run, the timing
version would have seemed faster.
I think this is sufficiently fast, and the patch simplifies the code. We
end up only checking "if (timing)"
in the few places that we print the timing...
Anything else to provide?
Show quoted text
Regards
Pavel
Executive Summary: 1,000,000 statements executed, consumes ~2 - 2.5
seconds of extra time (Total)So, the per statement cost is: 2.5s / 1,000,000 = 0.000,0025 s per
statement
Roughly: 2.5usUnfortunately, my test lines look like this:
Without Timing
done 0.198215 (500) *total *98.862548 *min* 0.167614 *avg*
0.19772509600000000000 *max *0.290659With Timing
done 0.191583 (500) *total* 100.729868 *min *0.163280 *avg *0.20145973600000000000
*max *0.275787Notice that the With Timing had a lower min, and a lower max. But a
higher average.
The distance between min - avg AND min - max, is big (those are for
1,000 selects each)Are these numbers at the "So What" Level?
While testing, I got the distinct impression that I am measuring
something that changes, or that the
variance in the system itself really swamps this on a per statement
basis. It's only impact is felt
on millions of PSQL queries, and that's a couple of seconds...Curious what others think before I take this any further.
regards, Kirk
Thanks!
[1]:
https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L278
[2]:
https://github.com/gurjeet/home/blob/08f1051fb854f4fc8fbc4f1326f393ed507a55ce/.bashrc#L262Best regards,
Gurjeet
http://Gurje.et
On Thu, Feb 23, 2023 at 2:05 PM Kirk Wolak <wolakk@gmail.com> wrote:
On Thu, Feb 23, 2023 at 9:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Heikki Linnakangas <hlinnaka@iki.fi> writes:
On 23/02/2023 13:20, Peter Eisentraut wrote:
If you don't have \timing turned on before the query starts, psql won't
record what the time was before the query, so you can't compute the run
time afterwards. This kind of feature would only work if you always
take the start time, even if \timing is turned off.Correct. That seems acceptable though? gettimeofday() can be slow on
some platforms, but I doubt it's *that* slow, that we couldn't call it
two times per query.Yeah, you'd need to capture both the start and stop times even if
\timing isn't on, in case you get asked later. But the backend is
going to call gettimeofday at least once per query, likely more
depending on what features you use. And there are inherently
multiple kernel calls involved in sending a query and receiving
a response. I tend to agree with Heikki that this overhead would
be unnoticeable. (Of course, some investigation proving that
wouldn't be unwarranted.)regards, tom lane
Note, for this above feature, I was thinking we have a ROW_COUNT variable
I use \set to see.
The simplest way to add this is maybe a set variable: EXEC_TIME
And it's set when ROW_COUNT gets set.
+1==
Now, since this opened a lively discussion, I am officially submitting my
first patch.
This includes the small change to prompt.c and the documentation. I had
help from Andrey Borodin,
and Pavel Stehule, who have supported me in how to propose, and use
gitlab, etc.We are programmers... It's literally our job to sharpen our tools. And
PSQL is one of my most used.
A small frustration, felt regularly was the motive.Regards, Kirk
PS: If I am supposed to edit the subject to say there is a patch here, I
did not know
PPS: I appreciate ANY and ALL feedback... This is how we learn!
Patch Posted with one edit, for line editings (Thanks Jim!)
Attachments:
v2-0001-Time-option-added-to-psql-prompt.patchtext/plain; charset=US-ASCII; name=v2-0001-Time-option-added-to-psql-prompt.patchDownload
From b9db157177bbdeeeb6d35c3623ca9355141419d7 Mon Sep 17 00:00:00 2001
From: Jim Jones <jim.jones@uni-muenster.de>
Date: Wed, 1 Mar 2023 00:07:55 +0100
Subject: [PATCH v2] Time option added to psql prompt
This adds a useful time option to the prompt: %T. Which does not
require a wasteful backquoted shell command which is also not
compatible between operating systems.
The format is simply HH24:MI:SS no other options available by design!
Author: Kirk Wolak <wolakk@gmail.com>
Reviewed-By: Andrey Borodin <amborodin@acm.org>
Reviewed-By: Nikolay Samokhvalov <samokhvalov@gmail.com>
Thread: https://postgr.es/m/CACLU5mSRwHr_8z%3DenMj-nXF1tmC7%2BJn5heZQNiKuLyxYUtL2fg%40mail.gmail.com
---
doc/src/sgml/ref/psql-ref.sgml | 9 +++++++++
src/bin/psql/prompt.c | 10 +++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index dc6528dc11..04ab9eeb8c 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -4575,6 +4575,15 @@ testdb=> <userinput>INSERT INTO my_table VALUES (:'content');</userinput>
</listitem>
</varlistentry>
+ <varlistentry id="app-psql-prompting-t-uc">
+ <term><literal>%T</literal></term>
+ <listitem>
+ <para>
+ The current time on the client in HH24:MI:SS format.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="app-psql-prompting-x">
<term><literal>%x</literal></term>
<listitem>
diff --git a/src/bin/psql/prompt.c b/src/bin/psql/prompt.c
index 969cd9908e..0c0c725df5 100644
--- a/src/bin/psql/prompt.c
+++ b/src/bin/psql/prompt.c
@@ -41,6 +41,7 @@
* or a ! if session is not connected to a database;
* in prompt2 -, *, ', or ";
* in prompt3 nothing
+ * %T - time in HH24:MI:SS format
* %x - transaction status: empty, *, !, ? (unknown or no connection)
* %l - The line number inside the current statement, starting from 1.
* %? - the error code of the last query (not yet implemented)
@@ -223,7 +224,14 @@ get_prompt(promptStatus_t status, ConditionalStack cstack)
break;
}
break;
-
+ /* output HH24:MI:SS */
+ case 'T':
+ {
+ time_t current_time = time(NULL);
+ struct tm *tm_info = localtime(¤t_time);
+ sprintf(buf, "%02d:%02d:%02d", tm_info->tm_hour, tm_info->tm_min, tm_info->tm_sec);
+ }
+ break;
case 'x':
if (!pset.db)
buf[0] = '?';
--
2.25.1
On 01.03.23 01:47, Kirk Wolak wrote:
Patch Posted with one edit, for line editings (Thanks Jim!)
The patch didn't pass the SanityCheck:
https://cirrus-ci.com/task/5445242183221248?logs=build#L1337
missing a header perhaps?
#include "time.h"
Best, Jim
On Wed, 22 Feb 2023 at 13:38, Kirk Wolak <wolakk@gmail.com> wrote:
I already requested ONLY the HH24 format. 8 characters of output. no options. It's a waste of time.
After all these years, sqlplus still has only one setting (show it, or not). I am asking the same here.
And I will gladly defend not changing it! Ever!
Yeah, well, it's kind of beside the point that you're satisfied with
this one format. We tend to think about what all users would expect
and what a complete feature would look like.
I actually tend to think this would be a nice feature. It's telling
that log files and other tracing tools tend to produce exactly this
type of output with every line prefixed with either a relative or
absolute timestamp.
I'm not sure if the *prompt* is a sensible place for it though. The
place it seems like it would be most useful is reading the output of
script executions where there would be no prompts. Perhaps it's the
command tags and \echo statements that should be timestamped.
And I think experience shows that there are three reasonable formats
for dates, the default LC_TIME format, ISO8601, and a relative
"seconds (with milliseconds) since starting". I think having a feature
that doesn't support those three would feel incomplete and eventually
need to be finished.
--
greg
Greg Stark <stark@mit.edu> writes:
I'm not sure if the *prompt* is a sensible place for it though. The
place it seems like it would be most useful is reading the output of
script executions where there would be no prompts. Perhaps it's the
command tags and \echo statements that should be timestamped.
Hmm, that is an interesting idea. I kind of like it, not least because
it eliminates most of the tension between wanting a complete timestamp
and wanting a short prompt. Command tags are short enough that there's
plenty of room.
And I think experience shows that there are three reasonable formats
for dates, the default LC_TIME format, ISO8601, and a relative
"seconds (with milliseconds) since starting". I think having a feature
that doesn't support those three would feel incomplete and eventually
need to be finished.
Yeah, I don't believe that one timestamp format is going to satisfy
everyone. But that was especially true when trying to wedge it
into the prompt, where the need for brevity adds more constraints.
regards, tom lane
ne 9. 4. 2023 v 3:54 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Greg Stark <stark@mit.edu> writes:
I'm not sure if the *prompt* is a sensible place for it though. The
place it seems like it would be most useful is reading the output of
script executions where there would be no prompts. Perhaps it's the
command tags and \echo statements that should be timestamped.Hmm, that is an interesting idea. I kind of like it, not least because
it eliminates most of the tension between wanting a complete timestamp
and wanting a short prompt. Command tags are short enough that there's
plenty of room.
I don't agree so there is a common request for a short prompt. Usually I
use four terminals on screen, and still my terminal has a width of 124
characters (and I use relatively small display of my Lenovo T520). Last
years I use prompt like:
(2023-04-09 06:08:30) postgres=# select 1;
┌──────────┐
│ ?column? │
╞══════════╡
│ 1 │
└──────────┘
(1 row)
and it is working. Nice thing when I paste the timestamp in examples. I
have not any problems with prompt width
Regards
Pavel
On 1 Mar 2023, at 10:29, Jim Jones <jim.jones@uni-muenster.de> wrote:
On 01.03.23 01:47, Kirk Wolak wrote:
Patch Posted with one edit, for line editings (Thanks Jim!)
The patch didn't pass the SanityCheck:
https://cirrus-ci.com/task/5445242183221248?logs=build#L1337
missing a header perhaps?
#include "time.h"
This patch spent the March commitfest not building and still doesn't build, so
I'm marking this returned with feedback. Please feel free to resubmit to the
next commitfest if there is renewed interest in the patch.
--
Daniel Gustafsson