From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Nikolay Samokhvalov <samokhvalov@gmail.com>,
        Kirk Wolak <wolakk@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Pavel Stehule <pavel.stehule@gmail.com>, amborodin86@gmail.com,
        Laurenz Albe <laurenz.albe@cybertec.at>
Subject: Re: Proposal: %T Prompt parameter for psql for current time (like Oracle has)
In-reply-to: <e0320ffa-97ac-5976-ea76-2b9e87dd054c@iki.fi>
References: <CACLU5mSRwHr_8z=enMj-nXF1tmC7+Jn5heZQNiKuLyxYUtL2fg@mail.gmail.com> <157609.1677088525@sss.pgh.pa.us> <CANNMO+KqqM0YpVUmVDec+9nku9ai9T=Y5Tp=pZ0rp1jR3d8kqA@mail.gmail.com> <f4013949-746d-23e7-118d-6a7e9fa70c37@iki.fi> <2f1c8cb9-6f4d-2a03-d069-c4f9c2b574ab@enterprisedb.com> <e0320ffa-97ac-5976-ea76-2b9e87dd054c@iki.fi>
Comments: In-reply-to Heikki Linnakangas <hlinnaka@iki.fi>
	message dated "Thu, 23 Feb 2023 14:09:19 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <414444.1677163935.1@sss.pgh.pa.us>
Date: Thu, 23 Feb 2023 09:52:15 -0500
Message-ID: <414445.1677163935@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/414445.1677163935%40sss.pgh.pa.us>
Precedence: bulk

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