Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Gavin Flower]

On 15/09/16 03:45, Robert Haas wrote:

On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger  wrote:

Today, i found the time to read all the mails in this thread, and i think i 
have to explain, why we decided to open a bug for this behavior.

Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote:

J. Random User: I'm having a problem!
Mailing List: Gee, how big are your tables?
J. Random User: Here's some pg_size_pretty output.
Mailing List: Gosh, we don't know what that means, what do you have
this obscure GUC set to?
J. Random User: Maybe I'll just give up on SQL and use MongoDB.

In fact, we had just the other way around. One of our most critical databases 
had some extreme bloat.
Some of our internal customers was very confused, about the sizes reported by 
the database.
This confusion has led to wrong decisions. (And a long discussion about the 
choice of DBMS btw)

I think there is a point missing in this whole discussion, or i just didn't see 
it:

Yeah, the behavior of "kB" is defined in the "postgresql.conf" documentation.
But no _user_ reads this. There is no link or hint in the documentation of 
"pg_size_pretty()" [1].

Interesting.  I think that our documentation should only describe the
way we use unit suffixes in one central place, but other places (like
pg_size_pretty) could link to that central place.

I don't believe that there is any general unanimity among users or
developers about the question of which suffixes devote units
denominated in units of 2^10 bytes vs. 10^3 bytes.  About once a year,
somebody makes an argument that we're doing it wrong, but the evidence
that I've seen is very mixed.  So when people say that there is only
one right way to do this and we are not in compliance with that one
right way, I guess I just don't believe it.  Not everybody likes the
way we do it, but I am fairly sure that if we change it, we'll make
some currently-unhappy people happy and some currently-happy people
unhappy.  And the people who don't care but wanted to preserve
backward compatibility will all be in the latter camp.

However, that is not to say that the documentation couldn't be better.

Well, I started programming 1968, and was taught that 1 kilobyte was 
1024 (2^10).


I object to Johny-come-latelies who try and insist it is 1000.

As regards 'kB' vs 'KB', I'm not too worried either way - I think 
consistency is more important



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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Tom Lane]

Robert Haas  writes:
> Interesting.  I think that our documentation should only describe the
> way we use unit suffixes in one central place, but other places (like
> pg_size_pretty) could link to that central place.

> I don't believe that there is any general unanimity among users or
> developers about the question of which suffixes devote units
> denominated in units of 2^10 bytes vs. 10^3 bytes.  About once a year,
> somebody makes an argument that we're doing it wrong, but the evidence
> that I've seen is very mixed.  So when people say that there is only
> one right way to do this and we are not in compliance with that one
> right way, I guess I just don't believe it.  Not everybody likes the
> way we do it, but I am fairly sure that if we change it, we'll make
> some currently-unhappy people happy and some currently-happy people
> unhappy.  And the people who don't care but wanted to preserve
> backward compatibility will all be in the latter camp.

That's about my position too: I cannot see that changing this is going
to make things better to a degree that would justify breaking backwards
compatibility.

> However, that is not to say that the documentation couldn't be better.

+1; your idea above seems sound.

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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Robert Haas]

On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger  wrote:
> Today, i found the time to read all the mails in this thread, and i think i 
> have to explain, why we decided to open a bug for this behavior.
>
> Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote:
>> J. Random User: I'm having a problem!
>> Mailing List: Gee, how big are your tables?
>> J. Random User: Here's some pg_size_pretty output.
>> Mailing List: Gosh, we don't know what that means, what do you have
>> this obscure GUC set to?
>> J. Random User: Maybe I'll just give up on SQL and use MongoDB.
>
> In fact, we had just the other way around. One of our most critical databases 
> had some extreme bloat.
> Some of our internal customers was very confused, about the sizes reported by 
> the database.
> This confusion has led to wrong decisions. (And a long discussion about the 
> choice of DBMS btw)
>
> I think there is a point missing in this whole discussion, or i just didn't 
> see it:
>
> Yeah, the behavior of "kB" is defined in the "postgresql.conf" documentation.
> But no _user_ reads this. There is no link or hint in the documentation of 
> "pg_size_pretty()" [1].

Interesting.  I think that our documentation should only describe the
way we use unit suffixes in one central place, but other places (like
pg_size_pretty) could link to that central place.

I don't believe that there is any general unanimity among users or
developers about the question of which suffixes devote units
denominated in units of 2^10 bytes vs. 10^3 bytes.  About once a year,
somebody makes an argument that we're doing it wrong, but the evidence
that I've seen is very mixed.  So when people say that there is only
one right way to do this and we are not in compliance with that one
right way, I guess I just don't believe it.  Not everybody likes the
way we do it, but I am fairly sure that if we change it, we'll make
some currently-unhappy people happy and some currently-happy people
unhappy.  And the people who don't care but wanted to preserve
backward compatibility will all be in the latter camp.

However, that is not to say that the documentation couldn't be better.

-- 
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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Thomas Berger]

Today, i found the time to read all the mails in this thread, and i think i 
have to explain, why we decided to open a bug for this behavior.

Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote:
> J. Random User: I'm having a problem!
> Mailing List: Gee, how big are your tables?
> J. Random User: Here's some pg_size_pretty output.
> Mailing List: Gosh, we don't know what that means, what do you have
> this obscure GUC set to?
> J. Random User: Maybe I'll just give up on SQL and use MongoDB.


In fact, we had just the other way around. One of our most critical databases 
had some extreme bloat.
Some of our internal customers was very confused, about the sizes reported by 
the database.
This confusion has led to wrong decisions. (And a long discussion about the 
choice of DBMS btw)

I think there is a point missing in this whole discussion, or i just didn't see 
it:

Yeah, the behavior of "kB" is defined in the "postgresql.conf" documentation.
But no _user_ reads this. There is no link or hint in the documentation of 
"pg_size_pretty()" [1].



[1] 
https://www.postgresql.org/docs/9.5/static/functions-admin.html#FUNCTIONS-ADMIN-DBSIZE


-- 
Thomas Berger

PostgreSQL DBA
Database Operations

1&1 Telecommunication SE | Ernst-Frey-Straße 10 | 76135 Karlsruhe | Germany
Phone: +49 721 91374-6566
E-Mail: thomas.ber...@1und1.de | Web: www.1und1.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 23963

Vorstand: Markus Huhn, Alessandro Nava, Moritz Roth, Ludger Sieverding, Martin 
Witt
Aufsichtsratsvorsitzender: Michael Scheeren


Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen 
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten 
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, 
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise 
auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient of this e-mail, you are hereby notified that saving, 
distribution or use of the content of this e-mail in any way is prohibited. If 
you have received this e-mail in error, please notify the sender and delete the 
e-mail.

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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Peter Eisentraut]

On 7/30/16 2:16 PM, Bruce Momjian wrote:
> The second patch does what Tom suggests above by outputting only "KB",
> and it supports "kB" for backward compatibility.  What it doesn't do is
> to allow arbitrary case, which I think would be a step backward.  The
> second patch actually does match the JEDEC standard, except for allowing
> "kB".

Btw., just to show that I'm not all crazy, the following programs also
display a small "k" for file sizes and download rates:

apt
curl
dnf
pip
yum
vagrant

-- 
Peter Eisentraut  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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Robert Haas]

On Tue, Aug 23, 2016 at 2:33 PM, Bruce Momjian  wrote:
> Well, the patch was updated several times, and the final version was not
> objected to until you objected.

It is not clear what you mean by "the final version", because you
posted two different final versions.  I don't see a clear vote from
anybody in favor of either of those things, and Peter's replies seem
to me to suggest that he does not support either of your proposals.
So I am not sure that I would agree with the statement that nobody
objected, but in any case there certainly wasn't a consensus in favor
of either change.

Also, the subject of this thread is "wrong suffix for pg_size_pretty",
which may not have tipped people off to the fact that you were
proposing to replace "kB" with "KB" everywhere.  Even after reading
your email, I didn't realize that you were proposing that until I
actually opened the patch and looked at it.  Such widespread changes
tend to draw objections, and IMHO shouldn't be made unless it's
abundantly clear that most people are in favor.

-- 
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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Alvaro Herrera]

Bruce Momjian wrote:
> On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian  wrote:
> > > That's why I was asking you to comment on the final patch, which I am
> > > planning to apply to PG 10 soon.
> > 
> > Oh, OK.  I didn't understand that that was what you are asking.  I
> > don't find either of your proposed final patches to be an improvement
> > over the status quo.  I think the selection of kB rather than KB was a
> > deliberate decision by Peter Eisentraut, and I don't think changing
> > our practice now buys us anything meaningful.  Your first patch
> > introduces an odd wart into the GUC mechanism, with a strange wording
> > for the message, to fix something that's not really broken in the
> > first place.  Your second one alters kB to KB in zillions of places
> > all over the code base, and I am quite sure that there is no consensus
> > to do anything of that sort.
> 
> Well, the patch was updated several times, and the final version was not
> objected to until you objected.  Does anyone else want to weigh in?

I think this should be left alone -- it looks more like pointless
tinkering than something useful.

-- 
Álvaro Herrerahttp://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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Tue, Aug 23, 2016 at 11:35:35AM -0700, Andres Freund wrote:
> On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote:
> > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian  wrote:
> > > > That's why I was asking you to comment on the final patch, which I am
> > > > planning to apply to PG 10 soon.
> > > 
> > > Oh, OK.  I didn't understand that that was what you are asking.  I
> > > don't find either of your proposed final patches to be an improvement
> > > over the status quo.  I think the selection of kB rather than KB was a
> > > deliberate decision by Peter Eisentraut, and I don't think changing
> > > our practice now buys us anything meaningful.  Your first patch
> > > introduces an odd wart into the GUC mechanism, with a strange wording
> > > for the message, to fix something that's not really broken in the
> > > first place.  Your second one alters kB to KB in zillions of places
> > > all over the code base, and I am quite sure that there is no consensus
> > > to do anything of that sort.
> > 
> > Well, the patch was updated several times, and the final version was not
> > objected to until you objected.  Does anyone else want to weigh in?
> 
> To me the change doesn't seem beneficial. Noise aside, the added
> whitespace seems even seems detrimental to me.  But I also don't really
> care much.

Well, right now we are inconsistent, so we should decide on the spacing
and make it consistent.  I think we are consistent on using 'k' instead
of 'K'.  There were at least eight people on this thread and when no one
objected to my final patch, I thought people wanted it.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Andres Freund]

On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote:
> On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian  wrote:
> > > That's why I was asking you to comment on the final patch, which I am
> > > planning to apply to PG 10 soon.
> > 
> > Oh, OK.  I didn't understand that that was what you are asking.  I
> > don't find either of your proposed final patches to be an improvement
> > over the status quo.  I think the selection of kB rather than KB was a
> > deliberate decision by Peter Eisentraut, and I don't think changing
> > our practice now buys us anything meaningful.  Your first patch
> > introduces an odd wart into the GUC mechanism, with a strange wording
> > for the message, to fix something that's not really broken in the
> > first place.  Your second one alters kB to KB in zillions of places
> > all over the code base, and I am quite sure that there is no consensus
> > to do anything of that sort.
> 
> Well, the patch was updated several times, and the final version was not
> objected to until you objected.  Does anyone else want to weigh in?

To me the change doesn't seem beneficial. Noise aside, the added
whitespace seems even seems detrimental to me.  But I also don't really
care much.


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian  wrote:
> > That's why I was asking you to comment on the final patch, which I am
> > planning to apply to PG 10 soon.
> 
> Oh, OK.  I didn't understand that that was what you are asking.  I
> don't find either of your proposed final patches to be an improvement
> over the status quo.  I think the selection of kB rather than KB was a
> deliberate decision by Peter Eisentraut, and I don't think changing
> our practice now buys us anything meaningful.  Your first patch
> introduces an odd wart into the GUC mechanism, with a strange wording
> for the message, to fix something that's not really broken in the
> first place.  Your second one alters kB to KB in zillions of places
> all over the code base, and I am quite sure that there is no consensus
> to do anything of that sort.

Well, the patch was updated several times, and the final version was not
objected to until you objected.  Does anyone else want to weigh in?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Robert Haas]

On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian  wrote:
> That's why I was asking you to comment on the final patch, which I am
> planning to apply to PG 10 soon.

Oh, OK.  I didn't understand that that was what you are asking.  I
don't find either of your proposed final patches to be an improvement
over the status quo.  I think the selection of kB rather than KB was a
deliberate decision by Peter Eisentraut, and I don't think changing
our practice now buys us anything meaningful.  Your first patch
introduces an odd wart into the GUC mechanism, with a strange wording
for the message, to fix something that's not really broken in the
first place.  Your second one alters kB to KB in zillions of places
all over the code base, and I am quite sure that there is no consensus
to do anything of that sort.

-- 
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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Tue, Aug 23, 2016 at 01:53:25PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian  wrote:
> >> I have already read the entire thread, and replied only after reading
> >> all messages.
> >
> > Well, what are you replying to then?
> 
> Your original message.  I'm arguing that we should not change the
> behavior, as you proposed to do.

That's why I was asking you to comment on the final patch, which I am
planning to apply to PG 10 soon.

> > There is no GUC used, and
> > everything is backward compatible.
> 
> Greg Stark proposed a GUC.  I don't think that's a good idea.  You
> proposed to change the behavior in a way that is not
> backward-compatible.  I don't think that's a good idea either.  If you
> are saying that you've dropped those proposals, fine, but I think it's
> entirely reasonable for me to express my opinion on them.  It was not
> evident to me that the thread had reached any kind of consensus.

Uh, the patch was the consensus, as I had several versions.  It was not
clear from your email what you thought of the patch, or if your comments
applied to the final patch at all.  The email you quoted was mine, but
from a very early stage in the discussion.

> > Your hyperbole about a new user
> > being confused is also not helpful.  What is this "chaos" you are
> > talking about?
> 
> Behavior-changing GUCs are bad news for reasons that have been
> discussed many times before: they create a requirement that everybody
> who writes code intended to run on arbitrary PostgreSQL installation
> be prepared to cater to every possible value of that GUC.
> pg_size_pretty() is pretty likely to appear in queries that we give
> users to run on their systems, so it would be a particularly poor
> choice to make its behavior configurable.

There is no question on that point.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Robert Haas]

On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian  wrote:
>> I have already read the entire thread, and replied only after reading
>> all messages.
>
> Well, what are you replying to then?

Your original message.  I'm arguing that we should not change the
behavior, as you proposed to do.

> There is no GUC used, and
> everything is backward compatible.

Greg Stark proposed a GUC.  I don't think that's a good idea.  You
proposed to change the behavior in a way that is not
backward-compatible.  I don't think that's a good idea either.  If you
are saying that you've dropped those proposals, fine, but I think it's
entirely reasonable for me to express my opinion on them.  It was not
evident to me that the thread had reached any kind of consensus.

> Your hyperbole about a new user
> being confused is also not helpful.  What is this "chaos" you are
> talking about?

Behavior-changing GUCs are bad news for reasons that have been
discussed many times before: they create a requirement that everybody
who writes code intended to run on arbitrary PostgreSQL installation
be prepared to cater to every possible value of that GUC.
pg_size_pretty() is pretty likely to appear in queries that we give
users to run on their systems, so it would be a particularly poor
choice to make its behavior configurable.

-- 
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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Tue, Aug 23, 2016 at 01:45:44PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian  wrote:
> > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian  wrote:
> >> > and the units were copied when pg_size_pretty() was implemented.  These
> >> > units are based on the International System of Units (SI)/metric.
> >> > However, the SI system is power-of-10-based, and we just re-purposed
> >> > them to be 1024 or 2^10-based.
> >> >
> >> > However, that is not the end of the story.
> >>
> >> Sure it is.  The behavior of the code matches the documentation.  The
> >> documentation describes one of several reasonable behaviors.  Full
> >> stop.
> >>
> >> > I am thinking Postgres 10 would be a good time to switch to KB as a
> >> > 1024-based prefix.  Unfortunately, there is no similar fix for MB, GB,
> >> > etc.  'm' is 'milli' so there we never used mB, so in JEDEC and Metric,
> >> > MB is ambiguous as 1000-based or 1024-based.
> >>
> >> I think this would be a backward compatibility break that would
> >> probably cause confusion for years.  I think we can add new functions
> >> that behave differently, but I oppose revising the behavior of the
> >> existing functions ... and I *definitely* oppose adding new
> >> behavior-changing GUCs.  The result of that will surely be chaos.
> >
> > Can you read up through August 1 and then reply?
> 
> I have already read the entire thread, and replied only after reading
> all messages.

Well, what are you replying to then?  There is no GUC used, and
everything is backward compatible.  Your hyperbole about a new user
being confused is also not helpful.  What is this "chaos" you are
talking about?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Robert Haas]

On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian  wrote:
> On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
>> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian  wrote:
>> > and the units were copied when pg_size_pretty() was implemented.  These
>> > units are based on the International System of Units (SI)/metric.
>> > However, the SI system is power-of-10-based, and we just re-purposed
>> > them to be 1024 or 2^10-based.
>> >
>> > However, that is not the end of the story.
>>
>> Sure it is.  The behavior of the code matches the documentation.  The
>> documentation describes one of several reasonable behaviors.  Full
>> stop.
>>
>> > I am thinking Postgres 10 would be a good time to switch to KB as a
>> > 1024-based prefix.  Unfortunately, there is no similar fix for MB, GB,
>> > etc.  'm' is 'milli' so there we never used mB, so in JEDEC and Metric,
>> > MB is ambiguous as 1000-based or 1024-based.
>>
>> I think this would be a backward compatibility break that would
>> probably cause confusion for years.  I think we can add new functions
>> that behave differently, but I oppose revising the behavior of the
>> existing functions ... and I *definitely* oppose adding new
>> behavior-changing GUCs.  The result of that will surely be chaos.
>
> Can you read up through August 1 and then reply?

I have already read the entire thread, and replied only after reading
all messages.

-- 
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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian  wrote:
> > and the units were copied when pg_size_pretty() was implemented.  These
> > units are based on the International System of Units (SI)/metric.
> > However, the SI system is power-of-10-based, and we just re-purposed
> > them to be 1024 or 2^10-based.
> >
> > However, that is not the end of the story.
> 
> Sure it is.  The behavior of the code matches the documentation.  The
> documentation describes one of several reasonable behaviors.  Full
> stop.
> 
> > I am thinking Postgres 10 would be a good time to switch to KB as a
> > 1024-based prefix.  Unfortunately, there is no similar fix for MB, GB,
> > etc.  'm' is 'milli' so there we never used mB, so in JEDEC and Metric,
> > MB is ambiguous as 1000-based or 1024-based.
> 
> I think this would be a backward compatibility break that would
> probably cause confusion for years.  I think we can add new functions
> that behave differently, but I oppose revising the behavior of the
> existing functions ... and I *definitely* oppose adding new
> behavior-changing GUCs.  The result of that will surely be chaos.

Can you read up through August 1 and then reply?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Robert Haas]

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian  wrote:
> The Postgres docs specify that kB is based on 1024 or 2^10:
>
> https://www.postgresql.org/docs/9.6/static/functions-admin.html
>
> Note: The units kB, MB, GB and TB used by the functions
> pg_size_pretty and pg_size_bytes are defined using powers of 2 rather
> than powers of 10, so 1kB is 1024 bytes, 1MB is 10242 = 1048576 bytes,
> and so on.
>
> These prefixes were introduced to GUC variable specification in 2006:
>
> commit b517e653489f733893d61e7a84c118325394471c
> Author: Peter Eisentraut 
> Date:   Thu Jul 27 08:30:41 2006 +
>
> Allow units to be specified with configuration settings.
>
> and added to postgresql.conf:
>
> # Memory units:  kB = kilobytesTime units:  ms  = milliseconds
> #MB = megabytes s   = seconds
> #GB = gigabytes min = minutes
> #TB = terabytes h   = hours
> #   d   = days
>
> and the units were copied when pg_size_pretty() was implemented.  These
> units are based on the International System of Units (SI)/metric.
> However, the SI system is power-of-10-based, and we just re-purposed
> them to be 1024 or 2^10-based.
>
> However, that is not the end of the story.

Sure it is.  The behavior of the code matches the documentation.  The
documentation describes one of several reasonable behaviors.  Full
stop.

> I am thinking Postgres 10 would be a good time to switch to KB as a
> 1024-based prefix.  Unfortunately, there is no similar fix for MB, GB,
> etc.  'm' is 'milli' so there we never used mB, so in JEDEC and Metric,
> MB is ambiguous as 1000-based or 1024-based.

I think this would be a backward compatibility break that would
probably cause confusion for years.  I think we can add new functions
that behave differently, but I oppose revising the behavior of the
existing functions ... and I *definitely* oppose adding new
behavior-changing GUCs.  The result of that will surely be chaos.

J. Random User: I'm having a problem!
Mailing List: Gee, how big are your tables?
J. Random User: Here's some pg_size_pretty output.
Mailing List: Gosh, we don't know what that means, what do you have
this obscure GUC set to?
J. Random User: Maybe I'll just give up on SQL and use MongoDB.

-- 
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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Pavel Stehule]

2016-08-01 20:51 GMT+02:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:

> On 7/30/16 1:18 AM, Pavel Stehule wrote:
> > We talked about this issue, when I wrote function pg_size_bytes. It is
> > hard to fix these functions after years of usage. The new set of
> > functions can be better
> >
> > pg_iso_size_pretty();
> > pg_iso_size_bytes();
>
> One thing that would actually be nice for other reasons as well is a
> version of pg_size_pretty() that lets you specify the output unit, say,
> as a second argument.  Because sometimes you want to compare two tables
> or something, and tells you one is 3GB and the other is 783MB, which
> doesn't really help.  If I tell it to use 'MB' as the output unit, I
> could get comparable output.
>

It is looks like some convert function

pg_size_to(size, unit, [others ... rounding, truncating]) returns numeric

select pg_size_to(1024*1024, 'KB')

Regards

Pavel


> --
> Peter Eisentraut  http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Mon, Aug  1, 2016 at 02:48:55PM -0400, Peter Eisentraut wrote:
> On 7/30/16 2:16 PM, Bruce Momjian wrote:
> > The second patch does what Tom suggests above by outputting only "KB",
> > and it supports "kB" for backward compatibility.  What it doesn't do is
> > to allow arbitrary case, which I think would be a step backward.  The
> > second patch actually does match the JEDEC standard, except for allowing
> > "kB".
> 
> If we're going to make changes, why not bite the bullet and output KiB?
> 
> I have never heard of JEDEC, so I'm less inclined to accept their
> "standard" at this point.

I already address this.  While I have never heard of JEDEC either, I
have seen KB, and have never seen KiB, hence my argument that KiB would
lead to more confusion than we have now.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Peter Eisentraut]

On 7/30/16 1:18 AM, Pavel Stehule wrote:
> We talked about this issue, when I wrote function pg_size_bytes. It is
> hard to fix these functions after years of usage. The new set of
> functions can be better
> 
> pg_iso_size_pretty();
> pg_iso_size_bytes();

One thing that would actually be nice for other reasons as well is a
version of pg_size_pretty() that lets you specify the output unit, say,
as a second argument.  Because sometimes you want to compare two tables
or something, and tells you one is 3GB and the other is 783MB, which
doesn't really help.  If I tell it to use 'MB' as the output unit, I
could get comparable output.

-- 
Peter Eisentraut  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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Peter Eisentraut]

On 7/30/16 2:16 PM, Bruce Momjian wrote:
> The second patch does what Tom suggests above by outputting only "KB",
> and it supports "kB" for backward compatibility.  What it doesn't do is
> to allow arbitrary case, which I think would be a step backward.  The
> second patch actually does match the JEDEC standard, except for allowing
> "kB".

If we're going to make changes, why not bite the bullet and output KiB?

I have never heard of JEDEC, so I'm less inclined to accept their
"standard" at this point.

-- 
Peter Eisentraut  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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Joshua D. Drake]

On 07/30/2016 11:16 AM, Bruce Momjian wrote:

On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote:

Greg Stark  writes:



I agree that a GUC and new functions are overkill --- we should just
decide on the format we want to output and what to support for input.

As logical as the IEC format appears, I just don't think the Ki/Mi/Gi
prefixes are used widely enough for us to use it --- I think it will
cause too many problem reports:

https://en.wikipedia.org/wiki/Binary_prefix

I have developed two possible patches for PG 10 --- the first one merely
allows "KB" to be used in addition to the existing "kB", and documents
this as an option.

The second patch does what Tom suggests above by outputting only "KB",
and it supports "kB" for backward compatibility.  What it doesn't do is
to allow arbitrary case, which I think would be a step backward.  The
second patch actually does match the JEDEC standard, except for allowing
"kB".

I also just applied a doc patch that increases case and spacing
consistency in the use of kB/MB/GB/TB.



+1


--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote:
> Greg Stark  writes:
> > I think Bruce's summary is a bit revisionist.
> 
> I would say it's a tempest in a teapot.
> 
> What I think we should do is accept "kb" and the rest case-insensitively,
> print them all in all-upper-case always, and tell standards pedants
> to get lost.  The idea of introducing either a GUC or new function names
> is just silly; it will cause far more confusion and user code breakage
> than will result from just leaving well enough alone.

I agree that a GUC and new functions are overkill --- we should just
decide on the format we want to output and what to support for input.

As logical as the IEC format appears, I just don't think the Ki/Mi/Gi
prefixes are used widely enough for us to use it --- I think it will
cause too many problem reports:

https://en.wikipedia.org/wiki/Binary_prefix

I have developed two possible patches for PG 10 --- the first one merely
allows "KB" to be used in addition to the existing "kB", and documents
this as an option.

The second patch does what Tom suggests above by outputting only "KB",
and it supports "kB" for backward compatibility.  What it doesn't do is
to allow arbitrary case, which I think would be a step backward.  The
second patch actually does match the JEDEC standard, except for allowing
"kB".

I also just applied a doc patch that increases case and spacing
consistency in the use of kB/MB/GB/TB.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
new file mode 100644
index 6ac5184..40038ac
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*** typedef struct
*** 694,700 
  #error XLOG_SEG_SIZE must be between 1MB and 1GB
  #endif
  
! static const char *memory_units_hint = gettext_noop("Valid units for this parameter are \"kB\", \"MB\", \"GB\", and \"TB\".");
  
  static const unit_conversion memory_unit_conversion_table[] =
  {
--- 694,700 
  #error XLOG_SEG_SIZE must be between 1MB and 1GB
  #endif
  
! static const char *memory_units_hint = gettext_noop("Valid units for this parameter are \"kB\"/\"KB\", \"MB\", \"GB\", and \"TB\".");
  
  static const unit_conversion memory_unit_conversion_table[] =
  {
*** convert_to_base_unit(int64 value, const
*** 5322,5328 
  	for (i = 0; *table[i].unit; i++)
  	{
  		if (base_unit == table[i].base_unit &&
! 			strcmp(unit, table[i].unit) == 0)
  		{
  			if (table[i].multiplier < 0)
  *base_value = value / (-table[i].multiplier);
--- 5322,5331 
  	for (i = 0; *table[i].unit; i++)
  	{
  		if (base_unit == table[i].base_unit &&
! 			(strcmp(unit, table[i].unit) == 0 ||
! 			 /* support the JEDEC standard which uses "KB" for 1024 */
! 			 (strcmp(unit, "KB") == 0 &&
! 			  strcmp(table[i].unit, "kB") == 0)))
  		{
  			if (table[i].multiplier < 0)
  *base_value = value / (-table[i].multiplier);
diff --git a/configure b/configure
new file mode 100755
index b49cc11..8466e5a
*** a/configure
--- b/configure
*** Optional Packages:
*** 1502,1511 
--with-libs=DIRSalternative spelling of --with-libraries
--with-pgport=PORTNUM   set default port number [5432]
--with-blocksize=BLOCKSIZE
!   set table block size in kB [8]
--with-segsize=SEGSIZE  set table segment size in GB [1]
--with-wal-blocksize=BLOCKSIZE
!   set WAL block size in kB [8]
--with-wal-segsize=SEGSIZE
set WAL segment size in MB [16]
--with-CC=CMD   set compiler (deprecated)
--- 1502,1511 
--with-libs=DIRSalternative spelling of --with-libraries
--with-pgport=PORTNUM   set default port number [5432]
--with-blocksize=BLOCKSIZE
!   set table block size in KB [8]
--with-segsize=SEGSIZE  set table segment size in GB [1]
--with-wal-blocksize=BLOCKSIZE
!   set WAL block size in KB [8]
--with-wal-segsize=SEGSIZE
set WAL segment size in MB [16]
--with-CC=CMD   set compiler (deprecated)
*** case ${blocksize} in
*** 3550,3557 
   32) BLCKSZ=32768;;
*) as_fn_error $? "Invalid block size. Allowed values are 1,2,4,8,16,32." "$LINENO" 5
  esac
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${blocksize}kB" >&5
! $as_echo "${blocksize}kB" >&6; }
  
  
  cat >>confdefs.h <<_ACEOF
--- 3550,3557 
   32) BLCKSZ=32768;;
*) as_fn_error $? "Invalid block size. Allowed values are 1,2,4,8,16,32." "$LINENO" 5
  esac
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${blocksize}KB" >&5
! $as_echo "${blocksize}KB" >&6; }
  
  
  cat >>confdefs.h <<_ACEOF
*** case 

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[David G. Johnston]

On Sat, Jul 30, 2016 at 10:35 AM, Tom Lane  wrote:

> Greg Stark  writes:
> > I think Bruce's summary is a bit revisionist.
>
> I would say it's a tempest in a teapot.
>
> What I think we should do is accept "kb" and the rest case-insensitively,
> print them all in all-upper-case always, and tell standards pedants
> to get lost.  The idea of introducing either a GUC or new function names
> is just silly; it will cause far more confusion and user code breakage
> than will result from just leaving well enough alone.
>

​I wouldn't mind fixing case sensitivity in the process...but I don't think
we need to touch the GUC infrastructure at all.

For a product that has a reasonably high regard for the SQL standard I'd
like to at least keep an open mind about other relevant standards - and if
accommodation is as simple as writing a new function I'd see no reason to
reject such a patch.​  pg_size_pretty never did seem like a good name for a
function with its behavior...lets be open to accepting an improved version
without a pg_ prefix.

We could even avoid a whole new function and add an "iB" template pattern
to the to_char function - although I'm not sure that wouldn't be more
confusing than helpful in practice.

David J.

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Tom Lane]

Greg Stark  writes:
> I think Bruce's summary is a bit revisionist.

I would say it's a tempest in a teapot.

What I think we should do is accept "kb" and the rest case-insensitively,
print them all in all-upper-case always, and tell standards pedants
to get lost.  The idea of introducing either a GUC or new function names
is just silly; it will cause far more confusion and user code breakage
than will result from just leaving well enough alone.

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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Greg Stark]

On Sat, Jul 30, 2016 at 2:47 AM, David G. Johnston
 wrote:
> After bouncing on this for a bit I'm inclined to mark the bug itself "won't
> fix" but introduce a "to_binary_iso" function (I'm hopeful a better name
> will emerge...) that will output a number using ISO binary suffixes.  I
> would document this under 9.8 "data type formatting functions" instead of
> within system functions.

I think Bruce's summary is a bit revisionist. All these standards are
attempts to reconcile two different conflicting traditions that have
been conflicting for decades. There's a conflict for a reason though
and the tradition of using powers of 2 is well-ingrained in plenty of
practices and software, not just Postgres.

Personally I'm pretty satisfied with the current mode of operation
because I think powers of 2 are vastly more useful and more likely to
be what the user actually wants. You would be hard pressed to find any
users actually typing KiB or MiB in config files and being surprised
they don't work or any users typing work_mem=100MB and being surprised
that they're not getting 95.367 MiB.

If you really want to support a strict interpretation of the SI
standards then I don't see anything wrong with having a GUC. It
doesn't change the semantics of SQL parsing so the worst-case downside
is that if you change the setting and then reload a config file or if
you move a setting from one place in a config file to another the
interpretation of the config file would change. The best practice
would probably be to set this config at the top of the config file and
nowhere else.


I would suggest having a GUC like "strict_si_units" with false as the
default. If it's true then units like KiB and KB are both accepted and
mean different things. If it's false then still accept both but treat
them as synonyms meaning powers of 2. This means users who don't care
can continue using convenient powers of 2 everywhere without thinking
about it and users who do can start using the new-fangled SI units
(and have the pitfall of accidentally specifying in units of powers of
10).

For outputs like pg_size_pretty, SHOW, and pg_settings you could
either say to always use KiB so that the outputs are always correct to
use regardless of the setting of strict_si_units or you could have it
print KB et al when strict_si_units is false -- the latter have the
advantage that outputs could be copied to older versions safely but
the disadvantage that if you change the setting then the
interpretation of existing config files change. I think it would be
better to print KiB/MiB etc always. I suppose there's the alternative
of trying to guess which unit results in the most concise display but
that seems unnecessarily baroque and likely to just hide mistakes
rather than help.

-- 
greg


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Pavel Stehule]

2016-07-30 3:47 GMT+02:00 David G. Johnston :

> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian  wrote:
>
>> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
>> > The following bug has been logged on the website:
>> >
>> > Bug reference:  14244
>> > Logged by:  Thomas Berger
>> > Email address:  thomas.ber...@1und1.de
>> > PostgreSQL version: 9.5.3
>> > Operating system:   any
>> > Description:
>> >
>> > pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the
>> returned
>> > value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and
>> > should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte
>> >
>> > =# select pg_size_pretty(1024000::bigint);
>> >  pg_size_pretty
>> > 
>> >  1000 kB
>>
>> (Thread moved to hackers.)
>>
>> Yes, we have redefined kB, and documented its use in postgresql.conf and
>> pg_size_pretty(), but it does not match any recognized standard.
>>
>
> ​After bouncing on this for a bit I'm inclined to mark the bug itself
> "won't fix" but introduce a "to_binary_iso" function (I'm hopeful a better
> name will emerge...) that will output a number using ISO binary suffixes.
> I would document this under 9.8 "data type formatting functions" instead of
> within system functions.
>
> pg_size_pretty output can continue with a defined role to be used as input
> into a GUC variable; and to keep backward compatibility.  Add a note near
> its definition to use "to_binary_iso" for a standard-conforming output
> string.
>

We talked about this issue, when I wrote function pg_size_bytes. It is hard
to fix these functions after years of usage. The new set of functions can
be better

pg_iso_size_pretty();
pg_iso_size_bytes();

or shorter name

pg_isize_pretty();
pg_isize_bytes();

Regards

Pavel


>
> ​David J.
>

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[David G. Johnston]

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian  wrote:

> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference:  14244
> > Logged by:  Thomas Berger
> > Email address:  thomas.ber...@1und1.de
> > PostgreSQL version: 9.5.3
> > Operating system:   any
> > Description:
> >
> > pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the
> returned
> > value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and
> > should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte
> >
> > =# select pg_size_pretty(1024000::bigint);
> >  pg_size_pretty
> > 
> >  1000 kB
>
> (Thread moved to hackers.)
>
> Yes, we have redefined kB, and documented its use in postgresql.conf and
> pg_size_pretty(), but it does not match any recognized standard.
>

​After bouncing on this for a bit I'm inclined to mark the bug itself
"won't fix" but introduce a "to_binary_iso" function (I'm hopeful a better
name will emerge...) that will output a number using ISO binary suffixes.
I would document this under 9.8 "data type formatting functions" instead of
within system functions.

pg_size_pretty output can continue with a defined role to be used as input
into a GUC variable; and to keep backward compatibility.  Add a note near
its definition to use "to_binary_iso" for a standard-conforming output
string.

​David J.

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Fri, Jul 29, 2016 at 08:18:38PM -0400, Bruce Momjian wrote:
> However, that is not the end of the story.  Things have moved forward
> since 2006 and there is now firm support for either KB or KiB to be
> 1024-based units.  This blog post explains the current state of prefix
> specification:
> 
>   
> http://pchelp.ricmedia.com/kilobytes-megabytes-gigabytes-terabytes-explained/
> 
> and here is a summary for 1000/1024-based units:
> 
>   Kilobyte (Binary, JEDEC)KB  1024
>   Kilobyte (Decimal, Metric)  kB  1000
>   Kibibyte (Binary, IEC)  KiB 1024

Oh, also, here is a Wikipedia article that has a nice chart on the top
right:

https://en.wikipedia.org/wiki/Binary_prefix

and a post that explains some of the background:


http://superuser.com/questions/938234/size-of-files-in-windows-os-its-kb-or-kb

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

[Bruce Momjian]

On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote:
> The following bug has been logged on the website:
> 
> Bug reference:  14244
> Logged by:  Thomas Berger
> Email address:  thomas.ber...@1und1.de
> PostgreSQL version: 9.5.3
> Operating system:   any
> Description:
> 
> pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the returned
> value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and
> should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte
> 
> =# select pg_size_pretty(1024000::bigint);   
>  pg_size_pretty 
> 
>  1000 kB

(Thread moved to hackers.)

The Postgres docs specify that kB is based on 1024 or 2^10:

https://www.postgresql.org/docs/9.6/static/functions-admin.html

Note: The units kB, MB, GB and TB used by the functions
pg_size_pretty and pg_size_bytes are defined using powers of 2 rather
than powers of 10, so 1kB is 1024 bytes, 1MB is 10242 = 1048576 bytes,
and so on.

These prefixes were introduced to GUC variable specification in 2006:

commit b517e653489f733893d61e7a84c118325394471c
Author: Peter Eisentraut 
Date:   Thu Jul 27 08:30:41 2006 +

Allow units to be specified with configuration settings.

and added to postgresql.conf:

# Memory units:  kB = kilobytesTime units:  ms  = milliseconds
#MB = megabytes s   = seconds
#GB = gigabytes min = minutes
#TB = terabytes h   = hours
#   d   = days

and the units were copied when pg_size_pretty() was implemented.  These
units are based on the International System of Units (SI)/metric.
However, the SI system is power-of-10-based, and we just re-purposed
them to be 1024 or 2^10-based.

However, that is not the end of the story.  Things have moved forward
since 2006 and there is now firm support for either KB or KiB to be
1024-based units.  This blog post explains the current state of prefix
specification:


http://pchelp.ricmedia.com/kilobytes-megabytes-gigabytes-terabytes-explained/

and here is a summary for 1000/1024-based units:

Kilobyte (Binary, JEDEC)KB  1024
Kilobyte (Decimal, Metric)  kB  1000
Kibibyte (Binary, IEC)  KiB 1024

You will notice that none of these list kB as 1024, which explains this
bug report.

Yes, we have redefined kB, and documented its use in postgresql.conf and
pg_size_pretty(), but it does not match any recognized standard.

I am thinking Postgres 10 would be a good time to switch to KB as a
1024-based prefix.  Unfortunately, there is no similar fix for MB, GB,
etc.  'm' is 'milli' so there we never used mB, so in JEDEC and Metric,
MB is ambiguous as 1000-based or 1024-based.

IEC does give us a unique specification for 'mega', MiB, and GiB, which
might be what we want to use, but that might be too big a change, and I
rarely see those.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


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