From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | thomas(dot)berger(at)1und1(dot)de, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty() |
Date: | 2016-08-23 17:30:29 |
Message-ID: | CA+TgmoY1KS_2CsJ9R+TKq_HuR-rdMYmtmDvX7FVd9e5GsX8hyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <bruce(at)momjian(dot)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 <peter_e(at)gmx(dot)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
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-08-23 17:43:07 | Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty() |
Previous Message | Jim Nasby | 2016-08-23 13:26:58 | Re: Re: [BUGS] Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5) |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-08-23 17:43:07 | Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty() |
Previous Message | Robert Haas | 2016-08-23 17:03:16 | Re: multivariate statistics (v19) |