On Sun, May 27, 2012 at 1:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
OK, let me propose another approach: add pg_size_pretty(int).
If we do this, all usability and performance problems will be solved.
Thought?
Attached patch adds pg_size_pretty(int).
Regards,
--
Fujii Masao