Re: Time measurement format - more human readable

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Bogdan Pilch <bogdan(at)matfyz(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Time measurement format - more human readable
Date: 2014-09-28 22:29:50
Message-ID: 54288BDE.8000807@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29/09/14 00:49, Bogdan Pilch wrote:
> Hi,
> I have created a small patch to postgres source (in particular the
> psql part of it) that modifies the way time spent executing the SQL
> commands is printed out.
>
> The idea is to have a human readable time printed, e.g.:
> Time: 1:32:15.45 m:s:ms
> Time: 2_10:12:55:444.033 d_h:m:s:ms
>
> Attached you can find a patch without any regression tests for that as
> this is practically impossible to test with regression tests. The
> duration of an SQL command (even though using pg_sleep) would differ
> on each machine and even between consecutive runs. Therefore one
> cannot specify a static expected output.
> My patch is relative to origin/REL9_4_STABLE branch as that is the one
> I started from.
>
> My plea is to have this change merged into the main stream so that it
> becomes available in upcoming releases.
>
> This modification does not require any interaction with user.
> It may create backward compatibility issues if some SQL developers
> assumed that the format is always <milis>.<micros>.
>
> regards
> bogdan
>
>
>
If this is a forced, and not optional, then I think it is a backward
step. IMnsHO

For programmatic analysis: either <milis>.<micros> or the number, of
seconds (with a fractional part), would be okay.

I would be happy if there was a configuration parameter to control it.
At least a simple boolean to choose between the new & old format - but
better still, would be a time format string to allow people to choose
the representation they consider most appropriate for their own needs.

Having a configuration parameter set to the original format, would also
avoid unnecessary backwards compatibility problems!

Cheers,
Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Flower 2014-09-28 22:41:47 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Peter Geoghegan 2014-09-28 21:22:52 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}