Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)

From: Kirk Wolak <wolakk(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, amborodin86(at)gmail(dot)com, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Andrey Borodin <amborodin(at)acm(dot)org>
Subject: Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)
Date: 2023-03-01 00:47:15
Message-ID: CACLU5mQL+Ct2+6GsQvHvKbW7dD3SH-D-uXK3fLKNDLuLzvnW=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 23, 2023 at 2:05 PM Kirk Wolak <wolakk(at)gmail(dot)com> wrote:

> On Thu, Feb 23, 2023 at 9:52 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Heikki Linnakangas <hlinnaka(at)iki(dot)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!)

Attachment Content-Type Size
v2-0001-Time-option-added-to-psql-prompt.patch text/plain 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-03-01 00:48:44 Re: Minimal logical decoding on standbys
Previous Message Imseih (AWS), Sami 2023-03-01 00:43:40 Re: Doc update for pg_stat_statements normalization