On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <br...@momjian.us> 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 <pete...@gmx.net>
>         Date:   Thu Jul 27 08:30:41 2006 +0000
>             Allow units to be specified with configuration settings.
> and added to postgresql.conf:
>         # Memory units:  kB = kilobytes        Time 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

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

Reply via email to