custom function for converting human readable sizes to bytes

On 11/21/15 12:49 AM, Pavel Stehule wrote:

I propose inversion function to pg_size_pretty function - like
pg_human_size.

Usage:

SELECT * FROM pg_class
WHERE pg_table_size(oid) > pg_human_size('2GB');

I'm not a big fan of the name, but +1 on the general idea.

Maybe pg_size_pretty(text)?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2015-11-22 18:30 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:

On 11/21/15 12:49 AM, Pavel Stehule wrote:

I propose inversion function to pg_size_pretty function - like
pg_human_size.

Usage:

SELECT * FROM pg_class
WHERE pg_table_size(oid) > pg_human_size('2GB');

I'm not a big fan of the name, but +1 on the general idea.

I am for any other good name

Maybe pg_size_pretty(text)?

I understand to your idea, but it can be too strange - function and
inversion function share same name.

What about pg_size(text), pg_size(value bigint, unit text) ?

Regards

Pavel

On 2015-11-22 18:30, Jim Nasby wrote:

On 11/21/15 12:49 AM, Pavel Stehule wrote:

I propose inversion function to pg_size_pretty function - like
pg_human_size.

Usage:

SELECT * FROM pg_class
WHERE pg_table_size(oid) > pg_human_size('2GB');

I'm not a big fan of the name, but +1 on the general idea.

Maybe pg_size_pretty(text)?

pg_ytterp_ezis(text)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11/22/15 2:11 PM, Pavel Stehule wrote:

What about pg_size(text), pg_size(value bigint, unit text) ?

I like, though I'd make it numeric or float. pg_size(3.5, 'GB')
certainly seems like a reasonable use case...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2015-11-22 21:19 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:

On 11/22/15 2:11 PM, Pavel Stehule wrote:

What about pg_size(text), pg_size(value bigint, unit text) ?

I like, though I'd make it numeric or float. pg_size(3.5, 'GB') certainly
seems like a reasonable use case...

yes, good note.

Regards

Pavel

Le 22 nov. 2015 21:29, "Pavel Stehule" <pavel.stehule@gmail.com> a écrit :

2015-11-22 21:19 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:

On 11/22/15 2:11 PM, Pavel Stehule wrote:

What about pg_size(text), pg_size(value bigint, unit text) ?

I like, though I'd make it numeric or float. pg_size(3.5, 'GB')

certainly seems like a reasonable use case...

yes, good note.

What about pg_size_unpretty()?

What about pg_size_unpretty()?

I was going to suggest pg_size_ugly(), but unpretty does emphasize the
inverse (rather than opposite) nature of the function.

2015-11-22 23:54 GMT+01:00 Corey Huinker <corey.huinker@gmail.com>:

What about pg_size_unpretty()?

I was going to suggest pg_size_ugly(), but unpretty does emphasize the
inverse (rather than opposite) nature of the function.

"unpretty", "ugly" aren't good names

maybe pg_size_bytes or different approach

we can introduce data type - bytesize - default input/output is human
readable text - and conversion to bigint is implicit

Some like

select .. where pg_table_size(oid) > bytesize '3.5GB'

and instead pg_size_pretty(pg_table_size(oid)) we can write
pg_table_size(oid)::bytesize

Regards

Pavel

On Sun, Nov 22, 2015 at 11:24 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

2015-11-22 23:54 GMT+01:00 Corey Huinker <corey.huinker@gmail.com>:

What about pg_size_unpretty()?

I was going to suggest pg_size_ugly(), but unpretty does emphasize the
inverse (rather than opposite) nature of the function.

"unpretty", "ugly" aren't good names

maybe pg_size_bytes or different approach

we can introduce data type - bytesize - default input/output is human
readable text - and conversion to bigint is implicit

Some like

select .. where pg_table_size(oid) > bytesize '3.5GB'

and instead pg_size_pretty(pg_table_size(oid)) we can write
pg_table_size(oid)::bytesize

Regards

Pavel

+1 to both pg_size_bytes() and ::bytesize. Both contribute to making the
statements more self-documenting.

On 11/23/15 3:11 AM, Corey Huinker wrote:

+1 to both pg_size_bytes() and ::bytesize. Both contribute to making the
statements more self-documenting.

The function seems like overkill to me if we have the type. Just my
opinion though. I'm thinking the type could just be called 'size' too
(or prettysize?). No reason it has to be tied to bytes (in particular
this would work for bits too).

If we're going to add this, I suppose it should support the 'i prefixes'
too (GiB, MiB, etc).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:

On 11/23/15 3:11 AM, Corey Huinker wrote:

+1 to both pg_size_bytes() and ::bytesize. Both contribute to making the
statements more self-documenting.

The function seems like overkill to me if we have the type. Just my
opinion though. I'm thinking the type could just be called 'size' too
(or prettysize?). No reason it has to be tied to bytes (in particular
this would work for bits too).

Please, no. That's *way* too generic a name.

I do not actually agree with making a type for this anyway. I can
tolerate a function, but adding a datatype is overkill; and it will
introduce far more definitional issues than it's worth. (eg, which
other types should have casts to/from it, and at what level)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2015-11-23 18:04 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:

On 11/23/15 3:11 AM, Corey Huinker wrote:

+1 to both pg_size_bytes() and ::bytesize. Both contribute to making the
statements more self-documenting.

The function seems like overkill to me if we have the type. Just my
opinion though. I'm thinking the type could just be called 'size' too
(or prettysize?). No reason it has to be tied to bytes (in particular
this would work for bits too).

Please, no. That's *way* too generic a name.

I do not actually agree with making a type for this anyway. I can
tolerate a function, but adding a datatype is overkill; and it will
introduce far more definitional issues than it's worth. (eg, which
other types should have casts to/from it, and at what level)

so pg_size_bytes is good enough for everybody?

Regards

Pavel

On 24/11/15 06:31, Pavel Stehule wrote:

2015-11-23 18:04 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>:

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:

On 11/23/15 3:11 AM, Corey Huinker wrote:

+1 to both pg_size_bytes() and ::bytesize. Both contribute to

making the

statements more self-documenting.

The function seems like overkill to me if we have the type. Just my
opinion though. I'm thinking the type could just be called

'size' too

(or prettysize?). No reason it has to be tied to bytes (in

particular

this would work for bits too).

Please, no. That's *way* too generic a name.

I do not actually agree with making a type for this anyway. I can
tolerate a function, but adding a datatype is overkill; and it will
introduce far more definitional issues than it's worth. (eg, which
other types should have casts to/from it, and at what level)

so pg_size_bytes is good enough for everybody?

Regards

Pavel

regards, tom lane

perhaps pg_size_bites for those people who want: KiB, MiB, GiB, TiB,
PiB, ,.. ??? :-)

Cheers,
Gavin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Pavel Stehule wrote:

so pg_size_bytes is good enough for everybody?

That seems good enough to me.

I would have it accept GiB and GB and have both transform to base 2, and
have an optional boolean flag whose non-default value turns the GB
interpretation into base 10, leaving the GiB interpretation unaffected.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Nov 23, 2015 at 1:47 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Pavel Stehule wrote:

so pg_size_bytes is good enough for everybody?

That seems good enough to me.

I would have it accept GiB and GB and have both transform to base 2, and
have an optional boolean flag whose non-default value turns the GB
interpretation into base 10, leaving the GiB interpretation unaffected.

I think it should be orange.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

2015-11-23 19:47 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>:

Pavel Stehule wrote:

so pg_size_bytes is good enough for everybody?

That seems good enough to me.

I would have it accept GiB and GB and have both transform to base 2, and
have an optional boolean flag whose non-default value turns the GB
interpretation into base 10, leaving the GiB interpretation unaffected.

attached proof concept based on parser "parse_int" from guc.c

It works well to 1TB what is enough for memory setting, but too low for
proposed target.

There are two ways

1. enhance the "parse_int"

2. using independent implementation - there is some redundant code, but we
can support duble insted int, and we can support some additional units.

Regards

Pavel

On 11/24/15 10:57 PM, Pavel Stehule wrote:

+ errmsg("parameter \"%s\" isn't valid size value",

Should read " isn't a valid size value"
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Nov 25, 2015 at 12:57 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:

Should read " isn't a valid size value"

http://www.postgresql.org/docs/devel/static/error-style-guide.html#AEN110918

| Contractions. Avoid contractions, like "can't"; use "cannot" instead.

So " is not a valid size value" would be better.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

2. using independent implementation - there is some redundant code, but we
can support duble insted int, and we can support some additional units.

new patch is based on own implementation - use numeric/bigint calculations

+ regress tests and doc

Regards

Pavel