Re: custom function for converting human readable sizes to bytes - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: custom function for converting human readable sizes to bytes
Date
Msg-id CAFj8pRBOOCbVUSA5_utnhsyZph0UiEx7RwyH9yZg-2Wi3o_eWA@mail.gmail.com
Whole thread Raw
In response to Re: custom function for converting human readable sizes to bytes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


2016-01-04 21:29 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Mon, Jan 4, 2016 at 12:17 PM, Shulgin, Oleksandr
<oleksandr.shulgin@zalando.de> wrote:
>> I'm also kind of wondering what the intended use case for this
>> function is.  Why do we want it?  Do we want it?
>
> As suggested above a usecase could be like the following:
>
> SELECT relname FROM pg_class WHERE pg_relation_size(oid) >
> pg_size_bytes('100 GB');
>
> I think it's neat and useful.

But you could also write SELECT relname FROM pg_class WHERE
pg_relation_size(oid) > 100 * 1024^3, which is actually fewer
characters.  Maybe pg_size_bytes('100 GB') is easier for some people
to remember than 100 * 1024^3, but I'm probably not one of those
people.

I am really one who hasn't memory for numbers - "100GB" is much more verbose for me. It is more clean in more complex maintenance queries. And if you need short syntax, you can write own SQL function

CREATE OR REPLACE FUNCTION size(text) RETURNS bigint AS $$ SELECT pg_size_bytes($1) $$ LANGUAGE sql;

then ... pg_relation_size(oid) > size('100GB')

Regards

Pavel
 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Broken lock management in policy.c.
Next
From: Stephen Frost
Date:
Subject: Re: Broken lock management in policy.c.