Re: Time measurement format - more human readable

On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
> 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

There are already a wide range of human readable time interval output 
formats available in the database; see the list at 
http://www.postgresql.org/docs/current/static/datatype-datetime.html#INTERVAL-STYLE-OUTPUT-TABLE

If none of those are acceptable to you, it would be difficult but not 
impossible to justify something new.  I could see tweaking one of those 
into a slightly updated new style aimed at this specific job, especially 
since it doesn't have to consider things like negative intervals.

There's value in printing time measurements using one of these interval 
styles sometimes, instead of the relatively raw values given right now.  
It would need to be an option though, and one that let the user allow 
choosing any of the supported interval formats. I personally would 
prefer to never see the existing format the number is reported in go 
away--too much software already expects it to be there, in that format.  
But adding this human readable version after that, when the user asks 
specifically for it, could be an acceptable addition.

So there's a rough spec for the job you'd have to take on here.  I'd 
expect it to expand in scope almost immediately to also consider the 
output of similar time intervals from mechanisms like 
log_min_duration_statement, too though, rather than just focusing on 
psql timing data.  There's a whole second round of almost inevitable 
scope creep to working on this.

If you were hoping what you submitted might be considered directly, 
sorry; that's not going to happen.  Handling input and output of times 
and dates is a very deep topic, and small patches trying to adjust such 
behavior without grappling with the full complexity are normally 
rejected outright.  There are cases where the existing code just has 
simple hacks in there now that could easily be whacked around.  But once 
the topic of cleaning those up appears, swapping to an alternate simple 
hack is rarely how that goes.  It normally heads toward considering the 
full right thing to do to handle all cases usefully.

-- 
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/