Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Bruce Momjian]

On Fri, Aug  5, 2016 at 02:07:18PM -0400, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian  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  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 +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Robert Haas]

On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Bruce Momjian]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Peter Eisentraut]

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.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Bruce Momjian]

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


kilo2.diff.gz
Description: application/gzip

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Christoph Berg]

Re: Peter Eisentraut 2016-08-01 

> > 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.ga28...@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
>   100 | 977KB  | -977KB
>10 | 954MB  | -954MB
> 1 | 931GB  | -931GB
>  1000 | 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Peter Eisentraut]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

[Bruce Momjian]

On Mon, Aug  1, 2016 at 01:35:53PM +0200, Christoph Berg wrote:
> Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@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
  100 | 977KB  | -977KB
   10 | 954MB  | -954MB
1 | 931GB  | -931GB
 1000 | 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  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 +
diff --git a/configure b/configure
new file mode 100755
index b49cc11..8466e5a
*** a/configure
--- b/configure
*** Optional Packages:
*** 1502,1511 
--with-libs=DIRSalternative spelling of --with-libraries
--with-pgport=PORTNUM   set default port number [5432]
--with-blocksize=BLOCKSIZE
!   set table block size in kB [8]
--with-segsize=SEGSIZE  set table segment size in GB [1]
--with-wal-blocksize=BLOCKSIZE
!   set WAL block size in kB [8]
--with-wal-segsize=SEGSIZE
set WAL segment size in MB [16]
--with-CC=CMD   set compiler (deprecated)
--- 1502,1511 
--with-libs=DIRSalternative spelling of --with-libraries
--with-pgport=PORTNUM   set default port number [5432]
--with-blocksize=BLOCKSIZE
!   set table block size in KB [8]
--with-segsize=SEGSIZE  set table segment size in GB [1]
--with-wal-blocksize=BLOCKSIZE
!   set WAL block size in KB [8]
--with-wal-segsize=SEGSIZE
set WAL segment size in MB [16]
--with-CC=CMD   set compiler (deprecated)
*** case ${blocksize} in
*** 3550,3557 
   32) BLCKSZ=32768;;
*) as_fn_error $? "Invalid block size. Allowed values are 1,2,4,8,16,32." "$LINENO" 5
  esac
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${blocksize}kB" >&5
! $as_echo "${blocksize}kB" >&6; }
  
  
  cat >>confdefs.h <<_ACEOF
--- 3550,3557 
   32) BLCKSZ=32768;;
*) as_fn_error $? "Invalid block size. Allowed values are 1,2,4,8,16,32." "$LINENO" 5
  esac
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${blocksize}KB" >&5
! $as_echo "${blocksize}KB" >&6; }
  
  
  cat >>confdefs.h <<_ACEOF
*** case ${wal_blocksize} in
*** 3638,3645 
   64) XLOG_BLCKSZ=65536;;
*) as_fn_error $? "Invalid WAL block size. Allowed values are 1,2,4,8,16,32,64." "$LINENO" 5
  esac
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${wal_blocksize}kB" >&5
! $as_echo "${wal_blocksize}kB" >&6; }
  
  
  cat >>confdefs.h <<_ACEOF
--- 3638,3645 
   64) XLOG_BLCKSZ=65536;;
*) as_fn_error $? "Invalid WAL block size. Allowed values are 1,2,4,8,16,32,64." "$LINENO" 5
  esac
! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${wal_blocksize}KB" 

[HACKERS] pg_size_pretty, SHOW, and spaces

[Christoph Berg]

Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@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 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.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers