On Sun, May 27, 2012 at 1:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@gmail.com> writes: >> On Sat, May 26, 2012 at 9:30 AM, Tom Lane <t...@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
size_pretty_int4_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
