@@ -217,11 +217,11 @@ function.
217217</caution>
218218
219219<para>
220- When a table or index exceeds 1GB , it is divided into gigabyte-sized
220+ When a table or index exceeds 1 GB , it is divided into gigabyte-sized
221221<firstterm>segments</>. The first segment's file name is the same as the
222222filenode; subsequent segments are named filenode.1, filenode.2, etc.
223223This arrangement avoids problems on platforms that have file size limitations.
224- (Actually, 1GB is just the default segment size. The segment size can be
224+ (Actually, 1 GB is just the default segment size. The segment size can be
225225adjusted using the configuration option <option>--with-segsize</option>
226226when building <productname>PostgreSQL</>.)
227227In principle, free space map and visibility map forks could require multiple
@@ -303,7 +303,7 @@ Oversized-Attribute Storage Technique).
303303
304304<para>
305305<productname>PostgreSQL</productname> uses a fixed page size (commonly
306- 8kB ), and does not allow tuples to span multiple pages. Therefore, it is
306+ 8 kB ), and does not allow tuples to span multiple pages. Therefore, it is
307307not possible to store very large field values directly. To overcome
308308this limitation, large field values are compressed and/or broken up into
309309multiple physical rows. This happens transparently to the user, with only
@@ -336,15 +336,15 @@ See <xref linkend="xtypes-toast"> for more detail.)
336336<acronym>TOAST</> usurps two bits of the varlena length word (the high-order
337337bits on big-endian machines, the low-order bits on little-endian machines),
338338thereby limiting the logical size of any value of a <acronym>TOAST</>-able
339- data type to 1GB (2<superscript>30</> - 1 bytes). When both bits are zero,
339+ data type to 1 GB (2<superscript>30</> - 1 bytes). When both bits are zero,
340340the value is an ordinary un-<acronym>TOAST</>ed value of the data type, and
341341the remaining bits of the length word give the total datum size (including
342342length word) in bytes. When the highest-order or lowest-order bit is set,
343343the value has only a single-byte header instead of the normal four-byte
344344header, and the remaining bits of that byte give the total datum size
345345(including length byte) in bytes. This alternative supports space-efficient
346346storage of values shorter than 127 bytes, while still allowing the data type
347- to grow to 1GB at need. Values with single-byte headers aren't aligned on
347+ to grow to 1 GB at need. Values with single-byte headers aren't aligned on
348348any particular boundary, whereas values with four-byte headers are aligned on
349349at least a four-byte boundary; this omission of alignment padding provides
350350additional space savings that is significant compared to short values.
@@ -420,10 +420,10 @@ bytes regardless of the actual size of the represented value.
420420<para>
421421The <acronym>TOAST</> management code is triggered only
422422when a row value to be stored in a table is wider than
423- <symbol>TOAST_TUPLE_THRESHOLD</> bytes (normally 2kB ).
423+ <symbol>TOAST_TUPLE_THRESHOLD</> bytes (normally 2 kB ).
424424The <acronym>TOAST</> code will compress and/or move
425425field values out-of-line until the row value is shorter than
426- <symbol>TOAST_TUPLE_TARGET</> bytes (also normally 2kB )
426+ <symbol>TOAST_TUPLE_TARGET</> bytes (also normally 2 kB )
427427or no more gains can be had. During an UPDATE
428428operation, values of unchanged fields are normally preserved as-is; so an
429429UPDATE 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
491491raw data size including the <acronym>TOAST</> table, and that the main table
492492contained only about 10% of the entire data (the URLs and some small HTML
493493pages). There was no run time difference compared to an un-<acronym>TOAST</>ed
494- comparison table, in which all the HTML pages were cut down to 7kB to fit.
494+ comparison table, in which all the HTML pages were cut down to 7 kB to fit.
495495</para>
496496
497497</sect2>
@@ -512,7 +512,7 @@ pointers to <firstterm>expanded</> data.
512512Indirect <acronym>TOAST</> pointers simply point at a non-indirect varlena
513513value stored somewhere in memory. This case was originally created merely
514514as a proof of concept, but it is currently used during logical decoding to
515- avoid possibly having to create physical tuples exceeding 1GB (as pulling
515+ avoid possibly having to create physical tuples exceeding 1 GB (as pulling
516516all out-of-line field values into the tuple might do). The case is of
517517limited use since the creator of the pointer datum is entirely responsible
518518that 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.
703703
704704<para>
705705Every table and index is stored as an array of <firstterm>pages</> of a
706- fixed size (usually 8kB , although a different page size can be selected
706+ fixed size (usually 8 kB , although a different page size can be selected
707707when compiling the server). In a table, all the pages are logically
708708equivalent, so a particular item (row) can be stored in any page. In
709709indexes, the first page is generally reserved as a <firstterm>metapage</>
0 commit comments