On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger <thomas.ber...@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 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()" .
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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers