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

On Tue, Jul 12, 2016 at 01:36:38PM +0000, thomas.berger@1und1.de wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      14244
> Logged by:          Thomas Berger
> Email address:      thomas.berger@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.htmlNote: The units kB, MB, GB and TB used by the
functionspg_size_prettyand pg_size_bytes are defined using powers of 2 ratherthan powers of 10, so 1kB is 1024 bytes,
1MBis 10242 = 1048576 bytes,and so on.
 

These prefixes were introduced to GUC variable specification in 2006:
commit b517e653489f733893d61e7a84c118325394471cAuthor: Peter Eisentraut <peter_e@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.  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    1024Kilobyte (Decimal, Metric)    kB    1000Kibibyte (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  <bruce@momjian.us>        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 +

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  <bruce@momjian.us>        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 +

On Sat, Jul 30, 2016 at 2:47 AM, David G. Johnston
<david.g.johnston@gmail.com> 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

Greg Stark <stark@mit.edu> 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

On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote:
> Greg Stark <stark@mit.edu> 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  <bruce@momjian.us>        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 +

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 <stark@mit.edu> 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.

Re: Bruce Momjian 2016-07-30 <20160730181643.GD22405@momjian.us>
> I also just applied a doc patch that increases case and spacing
> consistency in the use of kB/MB/GB/TB.

Hi,

PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:

# select pg_size_pretty((2^20)::bigint);pg_size_pretty
────────────────1024 kB

SHOW does not:

# show work_mem;work_mem
──────────1MB

The SHOW output is formatted by _ShowOption() using 'INT64_FORMAT "%s"',
via convert_from_base_unit(). The latter has a comment attached...
/** Convert a value in some base unit to a human-friendly unit.  The output* unit is chosen so that it's the greatest
unitthat can represent the value* without loss.  For example, if the base unit is GUC_UNIT_KB, 1024 is* converted to 1
MB,but 1025 is represented as 1025 kB.*/
 
... where the spaces are present again.

General typesetting standard seems to be "1 MB", i.e. to include a
space between value and unit. (This would also be my preference.)

Opinions? (I'd opt to insert spaces in the docs now, and then see if
inserting a space in the SHOW output is acceptable for 10.0.)

Christoph

On Mon, Aug  1, 2016 at 01:35:53PM +0200, Christoph Berg wrote:
> Re: Bruce Momjian 2016-07-30 <20160730181643.GD22405@momjian.us>
> > I also just applied a doc patch that increases case and spacing
> > consistency in the use of kB/MB/GB/TB.
>
> Hi,
>
> PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:
>
> # select pg_size_pretty((2^20)::bigint);
>  pg_size_pretty
> ────────────────
>  1024 kB
>
> SHOW does not:
>
> # show work_mem;
>  work_mem
> ──────────
>  1MB

Yes, that is inconsistent.  I have updated my attached patch to remove
spaces between the number and the units --- see below.

> The SHOW output is formatted by _ShowOption() using 'INT64_FORMAT "%s"',
> via convert_from_base_unit(). The latter has a comment attached...
> /*
>  * Convert a value in some base unit to a human-friendly unit.  The output
>  * unit is chosen so that it's the greatest unit that can represent the value
>  * without loss.  For example, if the base unit is GUC_UNIT_KB, 1024 is
>  * converted to 1 MB, but 1025 is represented as 1025 kB.
>  */
> ... where the spaces are present again.
>
> General typesetting standard seems to be "1 MB", i.e. to include a
> space between value and unit. (This would also be my preference.)
>
> Opinions? (I'd opt to insert spaces in the docs now, and then see if
> inserting a space in the SHOW output is acceptable for 10.0.)

I went through the docs a few days ago and committed a change to removed
spaces between the number and units in the few cases that had them ---
the majority didn't have spaces.

Looking at the Wikipedia article I posted earlier, that also doesn't use
spaces:

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

I think the only argument _for_ spaces is the output of pg_size_pretty()
now looks odd, e.g.:

               10 | 10 bytes       | -10 bytes
             1000 | 1000 bytes     | -1000 bytes
          1000000 | 977KB          | -977KB
       1000000000 | 954MB          | -954MB
    1000000000000 | 931GB          | -931GB
 1000000000000000 | 909TB          | -909TB
                    ^^^^^             ^^^^^

The issue is that we output "10 bytes", not "10bytes", but for units we
use "977KB".  That seems inconsistent, but it is the normal policy
people use.  I think this is because "977KB" is really "977K bytes", but
we just append the "B" after the "K" for bevity.

--
  Bruce Momjian  <bruce@momjian.us>        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 +

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

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

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  <bruce@momjian.us>        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 +

On 8/1/16 7:35 AM, Christoph Berg wrote:
> PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:
> 
> # select pg_size_pretty((2^20)::bigint);
>  pg_size_pretty
> ────────────────
>  1024 kB

because it's "pretty" :)

> SHOW does not:
> 
> # show work_mem;
>  work_mem
> ──────────
>  1MB

The original idea might have been to allow that value to be passed back
into the settings system, without having to quote the space.  I'm not
sure, but I think changing that might cause some annoyance.

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

Re: Peter Eisentraut 2016-08-01 <f3e021d3-d843-04a5-d816-6921309b3bf1@2ndquadrant.com>
> > PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:
> > 
> > # select pg_size_pretty((2^20)::bigint);
> >  pg_size_pretty
> > ────────────────
> >  1024 kB
> 
> because it's "pretty" :)

:)

> > SHOW does not:
> > 
> > # show work_mem;
> >  work_mem
> > ──────────
> >  1MB
> 
> The original idea might have been to allow that value to be passed back
> into the settings system, without having to quote the space.  I'm not
> sure, but I think changing that might cause some annoyance.

That's a good argument for keeping it that way, yes.


Re: Bruce Momjian 2016-08-01 <20160801162508.GA28246@momjian.us>
> Looking at the Wikipedia article I posted earlier, that also doesn't use
> spaces:
> 
>     https://en.wikipedia.org/wiki/Binary_prefix

That article has plenty of occurrences of "10 MB" "528 MB/s" and the
like.

> I think the only argument _for_ spaces is the output of pg_size_pretty()
> now looks odd, e.g.:
> 
>                10 | 10 bytes       | -10 bytes
>              1000 | 1000 bytes     | -1000 bytes
>           1000000 | 977KB          | -977KB
>        1000000000 | 954MB          | -954MB
>     1000000000000 | 931GB          | -931GB
>  1000000000000000 | 909TB          | -909TB
>                     ^^^^^             ^^^^^
> 
> The issue is that we output "10 bytes", not "10bytes", but for units we
> use "977KB".  That seems inconsistent, but it is the normal policy
> people use.  I think this is because "977KB" is really "977K bytes", but
> we just append the "B" after the "K" for bevity.

It's the other way round:

https://en.wikipedia.org/wiki/International_System_of_Units#General_rules

| The value of a quantity is written as a number followed by a space
| (representing a multiplication sign) and a unit symbol; e.g., 2.21 kg
[...]

I'd opt to omit the space anywhere where the value is supposed to be
fed back into the config (SHOW, --parameters), but use the "pretty"
format with space everywhere otherwise (documentation, memory counts
in explain output, pg_size_pretty() etc.)

Christoph

On Tue, Aug  2, 2016 at 11:29:01AM +0200, Christoph Berg wrote:
> > The issue is that we output "10 bytes", not "10bytes", but for units we
> > use "977KB".  That seems inconsistent, but it is the normal policy
> > people use.  I think this is because "977KB" is really "977K bytes", but
> > we just append the "B" after the "K" for bevity.
>
> It's the other way round:
>
> https://en.wikipedia.org/wiki/International_System_of_Units#General_rules
>
> | The value of a quantity is written as a number followed by a space
> | (representing a multiplication sign) and a unit symbol; e.g., 2.21 kg
> [...]
>
> I'd opt to omit the space anywhere where the value is supposed to be
> fed back into the config (SHOW, --parameters), but use the "pretty"
> format with space everywhere otherwise (documentation, memory counts
> in explain output, pg_size_pretty() etc.)

Yes, that's a strong argument for using a space.  I have adjusted the
patch to use spaces in all reasonable places.  Patch attached, which I
have gzipped because it was 133 KB.  (Ah, see what I did there?)  :-)

I am thinking of leaving the 9.6 docs alone as I have already made them
consistent (no space) with minimal changes.  We can make it consistent
the other way in PG 10.

--
  Bruce Momjian  <bruce@momjian.us>        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 +

On 8/2/16 12:51 PM, Bruce Momjian wrote:
> Yes, that's a strong argument for using a space.  I have adjusted the
> patch to use spaces in all reasonable places.  Patch attached, which I
> have gzipped because it was 133 KB.  (Ah, see what I did there?)  :-)
> 
> I am thinking of leaving the 9.6 docs alone as I have already made them
> consistent (no space) with minimal changes.  We can make it consistent
> the other way in PG 10.

I don't think anyone wanted to *remove* the spaces in the documentation.I think this change makes the documentation
harderto read.
 

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

On Fri, Aug  5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
> On 8/2/16 12:51 PM, Bruce Momjian wrote:
> > Yes, that's a strong argument for using a space.  I have adjusted the
> > patch to use spaces in all reasonable places.  Patch attached, which I
> > have gzipped because it was 133 KB.  (Ah, see what I did there?)  :-)
> > 
> > I am thinking of leaving the 9.6 docs alone as I have already made them
> > consistent (no space) with minimal changes.  We can make it consistent
> > the other way in PG 10.
> 
> I don't think anyone wanted to *remove* the spaces in the documentation.
>  I think this change makes the documentation harder to read.

Well, we had spaces in only a few places in the docs, and as I said, it
is not consistent.  Do you want those few put back for 9.6?

--  Bruce Momjian  <bruce@momjian.us>        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 +

On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, Aug  5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
>> On 8/2/16 12:51 PM, Bruce Momjian wrote:
>> > Yes, that's a strong argument for using a space.  I have adjusted the
>> > patch to use spaces in all reasonable places.  Patch attached, which I
>> > have gzipped because it was 133 KB.  (Ah, see what I did there?)  :-)
>> >
>> > I am thinking of leaving the 9.6 docs alone as I have already made them
>> > consistent (no space) with minimal changes.  We can make it consistent
>> > the other way in PG 10.
>>
>> I don't think anyone wanted to *remove* the spaces in the documentation.
>>  I think this change makes the documentation harder to read.
>
> Well, we had spaces in only a few places in the docs, and as I said, it
> is not consistent.  Do you want those few put back for 9.6?

+1 for that.  I can't see how it's good for 10 to be one way, 9.6 to
be the opposite way, and 9.5 and prior to be someplace in the middle.
That seems like a back-patching mess.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Aug  5, 2016 at 02:07:18PM -0400, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Fri, Aug  5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote:
> >> On 8/2/16 12:51 PM, Bruce Momjian wrote:
> >> > Yes, that's a strong argument for using a space.  I have adjusted the
> >> > patch to use spaces in all reasonable places.  Patch attached, which I
> >> > have gzipped because it was 133 KB.  (Ah, see what I did there?)  :-)
> >> >
> >> > I am thinking of leaving the 9.6 docs alone as I have already made them
> >> > consistent (no space) with minimal changes.  We can make it consistent
> >> > the other way in PG 10.
> >>
> >> I don't think anyone wanted to *remove* the spaces in the documentation.
> >>  I think this change makes the documentation harder to read.
> >
> > Well, we had spaces in only a few places in the docs, and as I said, it
> > is not consistent.  Do you want those few put back for 9.6?
> 
> +1 for that.  I can't see how it's good for 10 to be one way, 9.6 to
> be the opposite way, and 9.5 and prior to be someplace in the middle.
> That seems like a back-patching mess.

OK, done.

--  Bruce Momjian  <bruce@momjian.us>        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 +

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <bruce@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 <peter_e@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
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

On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <bruce@momjian.us> 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  <bruce@momjian.us>        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 +

On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> 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

On Tue, Aug 23, 2016 at 01:45:44PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> 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  <bruce@momjian.us>        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 +

On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian <bruce@momjian.us> 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

On Tue, Aug 23, 2016 at 01:53:25PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian <bruce@momjian.us> 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  <bruce@momjian.us>        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 +

On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian <bruce@momjian.us> 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

On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian <bruce@momjian.us> 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  <bruce@momjian.us>        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 +

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 <bruce@momjian.us> 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.

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 <bruce@momjian.us> 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  <bruce@momjian.us>        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 +

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 <bruce@momjian.us> 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 Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Aug 23, 2016 at 2:33 PM, Bruce Momjian <bruce@momjian.us> 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

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

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



[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.berger@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äßeAdressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und
vernichtenSie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern,
weiterzuleitenoder 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.
Ifyou have received this e-mail in error, please notify the sender and delete the e-mail. 

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

Robert Haas <robertmhaas@gmail.com> 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

On 15/09/16 03:45, Robert Haas wrote:
> 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
abug 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