Fujii Masao <masao.fujii@gmail.com> writes:
> On Sat, May 26, 2012 at 9:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The argument for adding pg_size_pretty(numeric) was pretty darn thin in
>> the first place, IMHO; it does not seem to me that it justified this
>> loss of usability.
> Ouch! But removing pg_size_pretty(numeric) causes another usability
> issue, e.g., pg_size_pretty(pg_xlog_location_diff(...)) fails. So how about
> removing pg_size_pretty(bigint) to resolve those two issues?
> I guess pg_size_pretty(numeric) is a bit slower than bigint version, but
> I don't think that such a bit slowdown of pg_size_pretty() becomes
> a matter practically. No?
AFAICS that argument is based on wishful thinking, not evidence.
I did some simple measurements and determined that at least on my
development machine, pg_size_pretty(numeric) is about a factor of four
slower than pg_size_pretty(bigint) --- and that's just counting the
function itself, not any added coercion-to-numeric processing. Now
maybe you could argue that it's never going to be used in a context
where anyone cares about its performance at all, but I've got doubts
about that.
In any case, it's probably too late to do anything about this for 9.2;
and once we ship it like that there will be little point in changing
it later, since people will already have had to add explicit casts
to any queries where the problem arises.
regards, tom lane