From 5ebad9a580d8f80943fd7095db14621278cc009c Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Fri, 5 Aug 2016 14:35:09 -0400 Subject: [PATCH] docs: re-add spaces before units removed This reverts the spaces before k/M/G/TB units removed for consistency in commit ca0c37b56f4a80ad758774e34c86cc4335583d29. Discussion: 20160802165116.GC32575@momjian.us --- doc/src/sgml/bloom.sgml | 4 ++-- doc/src/sgml/catalogs.sgml | 2 +- doc/src/sgml/config.sgml | 4 ++-- doc/src/sgml/datatype.sgml | 2 +- doc/src/sgml/installation.sgml | 14 +++++++------- doc/src/sgml/lobj.sgml | 4 ++-- doc/src/sgml/protocol.sgml | 2 +- doc/src/sgml/runtime.sgml | 10 +++++----- doc/src/sgml/storage.sgml | 20 ++++++++++---------- doc/src/sgml/wal.sgml | 6 +++--- 10 files changed, 34 insertions(+), 34 deletions(-) diff --git a/doc/src/sgml/bloom.sgml b/doc/src/sgml/bloom.sgml index fbec75d910..396348c523 100644 --- a/doc/src/sgml/bloom.sgml +++ b/doc/src/sgml/bloom.sgml @@ -177,7 +177,7 @@ CREATE INDEX query. We could reduce that by specifying a larger signature length. In this example, creating the index with length=200 reduced the number of false positives to 55; but it doubled the index size - (to 306MB) and ended up being slower for this query (125 ms overall). + (to 306 MB) and ended up being slower for this query (125 ms overall). @@ -202,7 +202,7 @@ CREATE INDEX Although this query runs much faster than with either of the single indexes, we pay a large penalty in index size. Each of the single-column - btree indexes occupies 214MB, so the total space needed is over 1.2GB, + btree indexes occupies 214 MB, so the total space needed is over 1.2GB, more than 8 times the space used by the bloom index. diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 8f5332ab52..8fd055b009 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -4021,7 +4021,7 @@ segments or pages small enough to be conveniently stored as rows in pg_largeobject. The amount of data per page is defined to be LOBLKSIZE (which is currently - BLCKSZ/4, or typically 2kB). + BLCKSZ/4, or typically 2 kB). diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index b9581d9f7b..02f917b375 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2702,7 +2702,7 @@ include_dir 'conf.d' checkpoints. This is a soft limit; WAL size can exceed max_wal_size under special circumstances, like under heavy load, a failing archive_command, or a high - wal_keep_segments setting. The default is 1GB. + wal_keep_segments setting. The default is 1 GB. Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf @@ -2723,7 +2723,7 @@ include_dir 'conf.d' always recycled for future use at a checkpoint, rather than removed. This can be used to ensure that enough WAL space is reserved to handle spikes in WAL usage, for example when running large batch - jobs. The default is 80MB. + jobs. The default is 80 MB. This parameter can only be set in the postgresql.conf file or on the server command line. diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 5c50f8deb9..67d0c349e0 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1120,7 +1120,7 @@ SELECT '52093.89'::money::numeric::float8; the physical requirement on disk might be less. Very long values are also stored in background tables so that they do not interfere with rapid access to shorter column values. In any case, the longest - possible character string that can be stored is about 1GB. (The + possible character string that can be stored is about 1 GB. (The maximum value that will be allowed for n in the data type declaration is less than that. It wouldn't be useful to change this because with multibyte character encodings the number of diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 98a151c598..a9968756e6 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -326,12 +326,12 @@ su - postgres Also check that you have sufficient disk space. You will need about - 100MB for the source tree during compilation and about 20MB for + 100 MB for the source tree during compilation and about 20 MB for the installation directory. An empty database cluster takes about - 35MB; databases take about five times the amount of space that a + 35 MB; databases take about five times the amount of space that a flat text file with the same data would take. If you are going to run the regression tests you will temporarily need up to an extra - 150MB. Use the df command to check free disk + 150 MB. Use the df command to check free disk space. @@ -2241,7 +2241,7 @@ createlang: language installation failed: ERROR: could not load library "/opt/d createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plperl.so": Bad address Another example is out of memory errors in the PostgreSQL server - logs, with every memory allocation near or greater than 256MB + logs, with every memory allocation near or greater than 256 MB failing. @@ -2250,8 +2250,8 @@ createlang: language installation failed: ERROR: could not load library "/opt/d and memory model used by the server process. By default, all binaries built on AIX are 32-bit. This does not depend upon hardware type or kernel in use. These 32-bit processes are - limited to 4GB of memory laid out in 256MB segments using one - of a few models. The default allows for less than 256MB in the + limited to 4 GB of memory laid out in 256 MB segments using one + of a few models. The default allows for less than 256 MB in the heap as it shares a single segment with the stack. @@ -2282,7 +2282,7 @@ createlang: language installation failed: ERROR: could not load library "/opt/d settings to find a configuration that works satisfactorily. This use of LDR_CNTRL tells AIX that you want the server to have MAXDATA bytes set aside for the - heap, allocated in 256MB segments. When you find a workable + heap, allocated in 256 MB segments. When you find a workable configuration, ldedit can be used to modify the binaries so that they default to using the desired heap size. PostgreSQL can diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml index f83e9cee2b..8726f0c701 100644 --- a/doc/src/sgml/lobj.sgml +++ b/doc/src/sgml/lobj.sgml @@ -50,8 +50,8 @@ larger than a single database page into a secondary storage area per table. This makes the large object facility partially obsolete. One remaining advantage of the large object facility is that it allows values - up to 4TB in size, whereas TOASTed fields can be at - most 1GB. Also, reading and updating portions of a large object can be + up to 4 TB in size, whereas TOASTed fields can be at + most 1 GB. Also, reading and updating portions of a large object can be done efficiently, while most operations on a TOASTed field will read or write the whole value as a unit. diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 8e701aab8c..9c96d8fc44 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1973,7 +1973,7 @@ The commands accepted in walsender mode are: Limit (throttle) the maximum amount of data transferred from server to client per unit of time. The expected unit is kilobytes per second. If this option is specified, the value must either be equal to zero - or it must fall within the range from 32kB through 1GB (inclusive). + or it must fall within the range from 32 kB through 1 GB (inclusive). If zero is passed or the option is not specified, no restriction is imposed on the transfer. diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 310bf735fc..8ba95e1b84 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -968,7 +968,7 @@ option SEMMAP=256 - The default maximum segment size is 32MB, and the + The default maximum segment size is 32 MB, and the default maximum total size is 2097152 pages. A page is almost always 4096 bytes except in unusual kernel configurations with huge pages @@ -977,7 +977,7 @@ option SEMMAP=256 The shared memory size settings can be changed via the - sysctl interface. For example, to allow 16GB: + sysctl interface. For example, to allow 16 GB: $ sysctl -w kernel.shmmax=17179869184 $ sysctl -w kernel.shmall=4194304 @@ -1032,7 +1032,7 @@ kern.sysv.shmall=1024 - SHMALL is measured in 4kB pages on this platform. + SHMALL is measured in 4 kB pages on this platform. @@ -1075,7 +1075,7 @@ sysctl -w kern.sysv.shmall - In the default configuration, only 512kB of shared memory per + In the default configuration, only 512 kB of shared memory per segment is allowed. To increase the setting, first change to the directory /etc/conf/cf.d. To display the current value of SHMMAX, run: @@ -1180,7 +1180,7 @@ project.max-msg-ids=(priv,4096,deny) On UnixWare 7, the maximum size for shared - memory segments is 512kB in the default configuration. + memory segments is 512 kB in the default configuration. To display the current value of SHMMAX, run: /etc/conf/bin/idtune -g SHMMAX diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml index 2d82953dbf..1b812bd0a9 100644 --- a/doc/src/sgml/storage.sgml +++ b/doc/src/sgml/storage.sgml @@ -217,11 +217,11 @@ function. -When a table or index exceeds 1GB, it is divided into gigabyte-sized +When a table or index exceeds 1 GB, it is divided into gigabyte-sized segments. The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. -(Actually, 1GB is just the default segment size. The segment size can be +(Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option when building PostgreSQL.) In principle, free space map and visibility map forks could require multiple @@ -303,7 +303,7 @@ Oversized-Attribute Storage Technique). PostgreSQL uses a fixed page size (commonly -8kB), and does not allow tuples to span multiple pages. Therefore, it is +8 kB), and does not allow tuples to span multiple pages. Therefore, it is not possible to store very large field values directly. To overcome this limitation, large field values are compressed and/or broken up into multiple physical rows. This happens transparently to the user, with only @@ -336,7 +336,7 @@ See for more detail.) TOAST usurps two bits of the varlena length word (the high-order bits on big-endian machines, the low-order bits on little-endian machines), thereby limiting the logical size of any value of a TOAST-able -data type to 1GB (230 - 1 bytes). When both bits are zero, +data type to 1 GB (230 - 1 bytes). When both bits are zero, the value is an ordinary un-TOASTed value of the data type, and the remaining bits of the length word give the total datum size (including length word) in bytes. When the highest-order or lowest-order bit is set, @@ -344,7 +344,7 @@ the value has only a single-byte header instead of the normal four-byte header, and the remaining bits of that byte give the total datum size (including length byte) in bytes. This alternative supports space-efficient storage of values shorter than 127 bytes, while still allowing the data type -to grow to 1GB at need. Values with single-byte headers aren't aligned on +to grow to 1 GB at need. Values with single-byte headers aren't aligned on any particular boundary, whereas values with four-byte headers are aligned on at least a four-byte boundary; this omission of alignment padding provides additional space savings that is significant compared to short values. @@ -420,10 +420,10 @@ bytes regardless of the actual size of the represented value. The TOAST management code is triggered only when a row value to be stored in a table is wider than -TOAST_TUPLE_THRESHOLD bytes (normally 2kB). +TOAST_TUPLE_THRESHOLD bytes (normally 2 kB). The TOAST code will compress and/or move field values out-of-line until the row value is shorter than -TOAST_TUPLE_TARGET bytes (also normally 2kB) +TOAST_TUPLE_TARGET bytes (also normally 2 kB) or no more gains can be had. During an UPDATE operation, values of unchanged fields are normally preserved as-is; so an UPDATE of a row with out-of-line values incurs no TOAST costs if @@ -491,7 +491,7 @@ containing typical HTML pages and their URLs was stored in about half of the raw data size including the TOAST table, and that the main table contained only about 10% of the entire data (the URLs and some small HTML pages). There was no run time difference compared to an un-TOASTed -comparison table, in which all the HTML pages were cut down to 7kB to fit. +comparison table, in which all the HTML pages were cut down to 7 kB to fit. @@ -512,7 +512,7 @@ pointers to expanded data. Indirect TOAST pointers simply point at a non-indirect varlena value stored somewhere in memory. This case was originally created merely as a proof of concept, but it is currently used during logical decoding to -avoid possibly having to create physical tuples exceeding 1GB (as pulling +avoid possibly having to create physical tuples exceeding 1 GB (as pulling all out-of-line field values into the tuple might do). The case is of limited use since the creator of the pointer datum is entirely responsible that the referenced data survives for as long as the pointer could exist, @@ -703,7 +703,7 @@ an item is a row; in an index, an item is an index entry. Every table and index is stored as an array of pages of a -fixed size (usually 8kB, although a different page size can be selected +fixed size (usually 8 kB, although a different page size can be selected when compiling the server). In a table, all the pages are logically equivalent, so a particular item (row) can be stored in any page. In indexes, the first page is generally reserved as a metapage diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml index 2089040d57..503ea8a2a7 100644 --- a/doc/src/sgml/wal.sgml +++ b/doc/src/sgml/wal.sgml @@ -475,7 +475,7 @@ linkend="guc-checkpoint-timeout"> seconds, or if is about to be exceeded, whichever comes first. - The default settings are 5 minutes and 1GB, respectively. + The default settings are 5 minutes and 1 GB, respectively. If no WAL has been written since the previous checkpoint, new checkpoints will be skipped even if checkpoint_timeout has passed. (If WAL archiving is being used and you want to put a lower limit on how @@ -735,10 +735,10 @@ WAL logs are stored in the directory pg_xlog under the data directory, as a set of - segment files, normally each 16MB in size (but the size can be changed + segment files, normally each 16 MB in size (but the size can be changed by altering the