diff --git a/doc/src/sgml/bloom.sgml b/doc/src/sgml/bloom.sgml
index 396348c5237e3cf5b17cc1dc54fff825a570c7e6..fbec75d910fc298e63b4659640da52e54d1584e2 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 <literal>length=200</>
reduced the number of false positives to 55; but it doubled the index size
- (to 306 MB) and ended up being slower for this query (125 ms overall).
+ (to 306MB) and ended up being slower for this query (125 ms overall).
</para>
<para>
@@ -202,7 +202,7 @@ CREATE INDEX
</programlisting>
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 214 MB, so the total space needed is over 1.2GB,
+ btree indexes occupies 214MB, so the total space needed is over 1.2GB,
more than 8 times the space used by the bloom index.
</para>
</sect2>
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 0689cc97205040a3a3051b390c6346295037b831..cbb333fb3ca3ceac49b0ddc2d1adca0ba73c557a 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -4021,7 +4021,7 @@
segments or <quote>pages</> small enough to be conveniently stored as rows
in <structname>pg_largeobject</structname>.
The amount of data per page is defined to be <symbol>LOBLKSIZE</> (which is currently
- <literal>BLCKSZ/4</>, or typically 2 kB).
+ <literal>BLCKSZ/4</>, or typically 2kB).
</para>
<para>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 4fb3186acf6c51a2267cb0cd762beb844566c111..b9581d9f7b2cbeee44a85d41cb7612236638f856 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1903,7 +1903,7 @@ include_dir 'conf.d'
cache, where performance might degrade. This setting may have no
effect on some platforms. The valid range is between
<literal>0</literal>, which disables controlled writeback, and
- <literal>2MB</literal>. The default is <literal>512Kb</> on Linux,
+ <literal>2MB</literal>. The default is <literal>512kB</> on Linux,
<literal>0</> elsewhere. (Non-default values of
<symbol>BLCKSZ</symbol> change the default and maximum.)
This parameter can only be set in the <filename>postgresql.conf</>
@@ -2660,7 +2660,7 @@ include_dir 'conf.d'
than the OS's page cache, where performance might degrade. This
setting may have no effect on some platforms. The valid range is
between <literal>0</literal>, which disables controlled writeback,
- and <literal>2MB</literal>. The default is <literal>256Kb</> on
+ and <literal>2MB</literal>. The default is <literal>256kB</> on
Linux, <literal>0</> elsewhere. (Non-default values of
<symbol>BLCKSZ</symbol> change the default and maximum.)
This parameter can only be set in the <filename>postgresql.conf</>
@@ -2702,7 +2702,7 @@ include_dir 'conf.d'
checkpoints. This is a soft limit; WAL size can exceed
<varname>max_wal_size</> under special circumstances, like
under heavy load, a failing <varname>archive_command</>, or a high
- <varname>wal_keep_segments</> setting. The default is 1 GB.
+ <varname>wal_keep_segments</> setting. The default is 1GB.
Increasing this parameter can increase the amount of time needed for
crash recovery.
This parameter can only be set in the <filename>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 80 MB.
+ jobs. The default is 80MB.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.
</para>
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 67d0c349e0c6a558ccc8ba2a7de6d2552ff4c832..5c50f8deb9b672d90a2fd853bda4d982ff448a40 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 1 GB. (The
+ possible character string that can be stored is about 1GB. (The
maximum value that will be allowed for <replaceable>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/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index b917bdd5b212310cc01ab3a404df1a292e780929..a30e25cfa088797a275ee08634ff0ee4c2dbfb4a 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -8165,7 +8165,7 @@ if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
<term><literal>sqlilongdata</></term>
<listitem>
<para>
- It equals to <literal>sqldata</literal> if <literal>sqllen</literal> is larger than 32KB.
+ It equals to <literal>sqldata</literal> if <literal>sqllen</literal> is larger than 32kB.
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index a9968756e652f2232b6bcca79665fe86f098cd8d..98a151c598327b37d78e526b6a3a2343d11b14eb 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -326,12 +326,12 @@ su - postgres
<para>
Also check that you have sufficient disk space. You will need about
- 100 MB for the source tree during compilation and about 20 MB for
+ 100MB for the source tree during compilation and about 20MB for
the installation directory. An empty database cluster takes about
- 35 MB; databases take about five times the amount of space that a
+ 35MB; 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
- 150 MB. Use the <command>df</command> command to check free disk
+ 150MB. Use the <command>df</command> command to check free disk
space.
</para>
</sect1>
@@ -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
</screen>
Another example is out of memory errors in the PostgreSQL server
- logs, with every memory allocation near or greater than 256 MB
+ logs, with every memory allocation near or greater than 256MB
failing.
</para>
@@ -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 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
+ 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
heap as it shares a single segment with the stack.
</para>
@@ -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 <symbol>LDR_CNTRL</symbol> tells AIX that you want the
server to have <symbol>MAXDATA</symbol> bytes set aside for the
- heap, allocated in 256 MB segments. When you find a workable
+ heap, allocated in 256MB segments. When you find a workable
configuration,
<command>ldedit</command> 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 8726f0c70136d682dfc43fec3814093f4540d359..f83e9cee2bde0441ad5f1a95f07f9e28425d1c33 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 4 TB in size, whereas <acronym>TOAST</acronym>ed fields can be at
- most 1 GB. Also, reading and updating portions of a large object can be
+ up to 4TB in size, whereas <acronym>TOAST</acronym>ed fields can be at
+ most 1GB. Also, reading and updating portions of a large object can be
done efficiently, while most operations on a <acronym>TOAST</acronym>ed
field will read or write the whole value as a unit.
</para>
diff --git a/doc/src/sgml/ltree.sgml b/doc/src/sgml/ltree.sgml
index 8a7a36390d3c8c9c428015b7df5a4e9a2c7f892f..fccfd320f5093184964df5c6a209dad1354b14d9 100644
--- a/doc/src/sgml/ltree.sgml
+++ b/doc/src/sgml/ltree.sgml
@@ -31,7 +31,7 @@
A <firstterm>label path</firstterm> is a sequence of zero or more
labels separated by dots, for example <literal>L1.L2.L3</>, representing
a path from the root of a hierarchical tree to a particular node. The
- length of a label path must be less than 65Kb, but keeping it under 2Kb is
+ length of a label path must be less than 65kB, but keeping it under 2kB is
preferable. In practice this is not a major limitation; for example,
the longest label path in the DMOZ catalog (<ulink
url="http://www.dmoz.org"></ulink>) is about 240 bytes.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 9c96d8fc44dce0423ceacdf71342494f2ddf1959..8e701aab8ce85107de1b0eedf9f39502648aab0e 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 32 kB through 1 GB (inclusive).
+ or it must fall within the range from 32kB through 1GB (inclusive).
If zero is passed or the option is not specified, no restriction is
imposed on the transfer.
</para>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index e3e254b3dcaa339a37f59b38a1ae8ca4ac67843a..4c5d748d0e4a0973e923abee589bd278aadc70da 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -968,7 +968,7 @@ option SEMMAP=256
</term>
<listitem>
<para>
- The default maximum segment size is 32 MB, and the
+ The default maximum segment size is 32MB, and the
default maximum total size is 2097152
pages. A page is almost always 4096 bytes except in unusual
kernel configurations with <quote>huge pages</quote>
@@ -977,7 +977,7 @@ option SEMMAP=256
<para>
The shared memory size settings can be changed via the
- <command>sysctl</command> interface. For example, to allow 16 GB:
+ <command>sysctl</command> interface. For example, to allow 16GB:
<screen>
<prompt>$</prompt> <userinput>sysctl -w kernel.shmmax=17179869184</userinput>
<prompt>$</prompt> <userinput>sysctl -w kernel.shmall=4194304</userinput>
@@ -1032,7 +1032,7 @@ kern.sysv.shmall=1024
</para>
<para>
- <varname>SHMALL</> is measured in 4 kB pages on this platform.
+ <varname>SHMALL</> is measured in 4kB pages on this platform.
</para>
<para>
@@ -1075,7 +1075,7 @@ sysctl -w kern.sysv.shmall
</term>
<listitem>
<para>
- In the default configuration, only 512 kB of shared memory per
+ In the default configuration, only 512kB of shared memory per
segment is allowed. To increase the setting, first change to the
directory <filename>/etc/conf/cf.d</>. To display the current value of
<varname>SHMMAX</>, run:
@@ -1180,7 +1180,7 @@ project.max-msg-ids=(priv,4096,deny)
<listitem>
<para>
On <productname>UnixWare</> 7, the maximum size for shared
- memory segments is 512 kB in the default configuration.
+ memory segments is 512kB in the default configuration.
To display the current value of <varname>SHMMAX</>, run:
<programlisting>
/etc/conf/bin/idtune -g SHMMAX
diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
index 6a22054ec84c8a1da600d3f782716a10d7b6df0d..f40c7906124022a3fd2a4101acff98430d76e951 100644
--- a/doc/src/sgml/spgist.sgml
+++ b/doc/src/sgml/spgist.sgml
@@ -755,7 +755,7 @@ typedef struct spgLeafConsistentOut
<para>
Individual leaf tuples and inner tuples must fit on a single index page
- (8KB by default). Therefore, when indexing values of variable-length
+ (8kB by default). Therefore, when indexing values of variable-length
data types, long values can only be supported by methods such as radix
trees, in which each level of the tree includes a prefix that is short
enough to fit on a page, and the final leaf level includes a suffix also
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
index 1b812bd0a994cdc3a10b9458e1b71acbc5fc949c..2d82953dbf60ad3ac8ebf78b7bdcd0f994ad8adb 100644
--- a/doc/src/sgml/storage.sgml
+++ b/doc/src/sgml/storage.sgml
@@ -217,11 +217,11 @@ function.
</caution>
<para>
-When a table or index exceeds 1 GB, it is divided into gigabyte-sized
+When a table or index exceeds 1GB, it is divided into gigabyte-sized
<firstterm>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, 1 GB is just the default segment size. The segment size can be
+(Actually, 1GB is just the default segment size. The segment size can be
adjusted using the configuration option <option>--with-segsize</option>
when building <productname>PostgreSQL</>.)
In principle, free space map and visibility map forks could require multiple
@@ -303,7 +303,7 @@ Oversized-Attribute Storage Technique).
<para>
<productname>PostgreSQL</productname> uses a fixed page size (commonly
-8 kB), and does not allow tuples to span multiple pages. Therefore, it is
+8kB), 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 <xref linkend="xtypes-toast"> for more detail.)
<acronym>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 <acronym>TOAST</>-able
-data type to 1 GB (2<superscript>30</> - 1 bytes). When both bits are zero,
+data type to 1GB (2<superscript>30</> - 1 bytes). When both bits are zero,
the value is an ordinary un-<acronym>TOAST</>ed 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 1 GB at need. Values with single-byte headers aren't aligned on
+to grow to 1GB 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.
<para>
The <acronym>TOAST</> management code is triggered only
when a row value to be stored in a table is wider than
-<symbol>TOAST_TUPLE_THRESHOLD</> bytes (normally 2 kB).
+<symbol>TOAST_TUPLE_THRESHOLD</> bytes (normally 2kB).
The <acronym>TOAST</> code will compress and/or move
field values out-of-line until the row value is shorter than
-<symbol>TOAST_TUPLE_TARGET</> bytes (also normally 2 kB)
+<symbol>TOAST_TUPLE_TARGET</> bytes (also normally 2kB)
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 <acronym>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 <acronym>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-<acronym>TOAST</>ed
-comparison table, in which all the HTML pages were cut down to 7 kB to fit.
+comparison table, in which all the HTML pages were cut down to 7kB to fit.
</para>
</sect2>
@@ -512,7 +512,7 @@ pointers to <firstterm>expanded</> data.
Indirect <acronym>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 1 GB (as pulling
+avoid possibly having to create physical tuples exceeding 1GB (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.
<para>
Every table and index is stored as an array of <firstterm>pages</> of a
-fixed size (usually 8 kB, although a different page size can be selected
+fixed size (usually 8kB, 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 <firstterm>metapage</>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 503ea8a2a7e913d1be7df792f2b1e7b092ee5c7f..2089040d57602d5167a03ad628a3015308e51b2f 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -475,7 +475,7 @@
linkend="guc-checkpoint-timeout"> seconds, or if
<xref linkend="guc-max-wal-size"> is about to be exceeded,
whichever comes first.
- The default settings are 5 minutes and 1 GB, respectively.
+ The default settings are 5 minutes and 1GB, respectively.
If no WAL has been written since the previous checkpoint, new checkpoints
will be skipped even if <varname>checkpoint_timeout</> has passed.
(If WAL archiving is being used and you want to put a lower limit on how
@@ -735,10 +735,10 @@
<para>
<acronym>WAL</acronym> logs are stored in the directory
<filename>pg_xlog</filename> under the data directory, as a set of
- segment files, normally each 16 MB in size (but the size can be changed
+ segment files, normally each 16MB in size (but the size can be changed
by altering the <option>--with-wal-segsize</> configure option when
building the server). Each segment is divided into pages, normally
- 8 kB each (this size can be changed via the <option>--with-wal-blocksize</>
+ 8kB each (this size can be changed via the <option>--with-wal-blocksize</>
configure option). The log record headers are described in
<filename>access/xlogrecord.h</filename>; the record content is dependent
on the type of event that is being logged. Segment files are given