On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger <Thomas.Berger@1und1.de> 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
bugfor 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