Robert Haas wrote:
> You know, if we implemented what Tom proposed here:
>
> http://archives.postgresql.org/pgsql-hackers/2012-08/msg01055.php
>
> ...then we probably get away with removing pg_size_pretty(bigint)
> and then this would Just Work. pg_size_pretty(numeric) is doubtless
> a little slower than pg_size_pretty(bigint), but I think in
> practice nobody's going to care.
The worst case I was able to generate in some testing on an older
(over five year old) desktop machine, was 4000ns for the numeric form
versus 500ns for the bigint form. So one way of looking at it is
that it can be up to eight times slower. The other way of looking
at it is that it can take up to 3500ns extra to generate a string
intended for human consumption -- this is not a format you generate
for maching parsing. I rarely run a query that generates more than a
few thousand of these values; to it would be rare for it to cost me
more than about 15ms on a query run which was intended for visual
review. The difference is probably going to be much smaller on most
machines purchased for database server usage within, say, the last
three years.
I don't know about anyone else, but I could live with that.
-Kevin