mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Markup additions and spell check. (covers User's Guide)

Browse Source
This commit is contained in:
Peter Eisentraut 2001-09-09 17:21:59 +00:00
parent ba708ea3dc
commit 84956e71a3
16 changed files with 714 additions and 706 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/sgml/array.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.11 2001/05/12 22:51:34 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.12 2001/09/09 17:21:44 petere Exp $ -->
<chapter id="arrays">
<title>Arrays</title>
@ -9,7 +9,7 @@
<para>
<productname>Postgres</productname> allows columns of a table to be
defined as variable-length multi-dimensional arrays. Arrays of any
defined as variable-length multidimensional arrays. Arrays of any
built-in type or user-defined type can be created. To illustrate
their use, we create this table:
<programlisting>

112
doc/src/sgml/datatype.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.61 2001/09/04 03:17:54 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.62 2001/09/09 17:21:51 petere Exp $
-->
<chapter id="datatype">
@ -361,59 +361,59 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.61 2001/09/04 03:17:54 mo
<tbody>
<row>
<entry>smallint</entry>
<entry><type>smallint</></entry>
<entry>2 bytes</entry>
<entry>Fixed-precision</entry>
<entry>-32768 to +32767</entry>
</row>
<row>
<entry>integer</entry>
<entry><type>integer</></entry>
<entry>4 bytes</entry>
<entry>Usual choice for fixed-precision</entry>
<entry>-2147483648 to +2147483647</entry>
</row>
<row>
<entry>bigint</entry>
<entry><type>bigint</></entry>
<entry>8 bytes</entry>
<entry>Very large range fixed-precision</entry>
<entry>about 18 decimal digits</entry>
</row>
<row>
<entry>decimal</entry>
<entry><type>decimal</></entry>
<entry>variable</entry>
<entry>user-specified precision, exact</entry>
<entry>no limit</entry>
</row>
<row>
<entry>numeric</entry>
<entry><type>numeric</></entry>
<entry>variable</entry>
<entry>user-specified precision, exact</entry>
<entry>no limit</entry>
</row>
<row>
<entry>real</entry>
<entry><type>real</></entry>
<entry>4 bytes</entry>
<entry>variable-precision, inexact</entry>
<entry>6 decimal digits precision</entry>
</row>
<row>
<entry>double precision</entry>
<entry><type>double precision</></entry>
<entry>8 bytes</entry>
<entry>variable-precision, inexact</entry>
<entry>15 decimal digits precision</entry>
</row>
<row>
<entry>serial</entry>
<entry><type>serial</></entry>
<entry>4 bytes</entry>
<entry>autoincrementing integer</entry>
<entry>1 to 2147483647</entry>
</row>
<row>
<entry>bigserial</entry>
<entry><type>bigserial</type></entry>
<entry>8 bytes</entry>
<entry>autoincrementing integer</entry>
<entry>1 to 9223372036854775807</entry>
@ -557,7 +557,7 @@ NUMERIC
<para>
The data types <type>real</type> and <type>double
precision</type> are inexact, variable precision numeric types.
In practice, these types are usually implementations of IEEE 754
In practice, these types are usually implementations of <acronym>IEEE</acronym> 754
binary floating point (single and double precision,
respectively), to the extent that the underlying processor,
operating system, and compiler support it.
@ -636,7 +636,7 @@ NUMERIC
</indexterm>
<para>
The <type>serial</type> datatypes are not truly types, but are a
The <type>serial</type> data types are not truly types, but are a
notational convenience for setting up unique identifier columns
in tables.
In the current implementation, specifying
@ -777,21 +777,17 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
</thead>
<tbody>
<row>
<entry>character(<replaceable>n</>), char(<replaceable>n</>)</entry>
<entry><type>character(<replaceable>n</>)</type>, <type>char(<replaceable>n</>)</type></entry>
<entry>Fixed-length blank padded</entry>
</row>
<row>
<entry>character varying(<replaceable>n</>), varchar(<replaceable>n</>)</entry>
<entry><type>character varying(<replaceable>n</>)</type>, <type>varchar(<replaceable>n</>)</type></entry>
<entry>Variable-length with limit</entry>
</row>
<row>
<entry>text</entry>
<entry><type>text</type></entry>
<entry>Variable unlimited length</entry>
</row>
<row>
<entry>bytea</entry>
<entry>binary data</entry>
</row>
</tbody>
</tgroup>
</table>
@ -839,19 +835,6 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
standard, many other RDBMS packages have it as well.
</para>
<para>
The <type>bytea</type> data type allows storage of binary data,
specifically allowing storage of NULLs which are entered as
<literal>'\\000'</>. The first backslash is interpreted by the
single quotes, and the second is recognized by <type>bytea</> and
preceeds a three digit octal value. For a similar reason, a
backslash must be entered into a field as <literal>'\\\\'</> or
<literal>'\\134'</>. You may also have to escape line feeds and
carriage return if your interface automatically translates these. It
can store values of any length. <type>Bytea</> is a non-standard
data type.
</para>
<para>
The storage requirement for data of these types is 4 bytes plus
the actual string, and in case of <type>character</type> plus the
@ -860,7 +843,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
that can be stored is about 1 GB. (The maximum value that will be
allowed for <replaceable>n</> in the data type declaration is
actually larger than that. It wouldn't be very useful to change
this because with multi-byte character encodings the number of
this because with multibyte character encodings the number of
characters and bytes can be quite different anyway.)
</para>
@ -957,6 +940,23 @@ SELECT b, char_length(b) FROM test2;
</sect1>
<sect1 id="datatype-binary">
<title>Binary Data</title>
<para>
The <type>bytea</type> data type allows storage of binary data,
specifically allowing storage of NULLs which are entered as
<literal>'\\000'</>. The first backslash is interpreted by the
single quotes, and the second is recognized by <type>bytea</> and
precedes a three digit octal value. For a similar reason, a
backslash must be entered into a field as <literal>'\\\\'</> or
<literal>'\\134'</>. You may also have to escape line feeds and
carriage return if your interface automatically translates these. It
can store values of any length. <type>Bytea</> is a non-standard
data type.
</para>
</sect1>
<sect1 id="datatype-datetime">
<title>Date/Time Types</title>
@ -1083,7 +1083,7 @@ SELECT b, char_length(b) FROM test2;
</para>
<sect3>
<title>date</title>
<title><type>date</type></title>
<indexterm>
<primary>date</primary>
@ -1260,7 +1260,7 @@ SELECT b, char_length(b) FROM test2;
</sect3>
<sect3>
<title>time [ without time zone ]</title>
<title><type>time [ without time zone ]</type></title>
<indexterm>
<primary>time</primary>
@ -1328,7 +1328,7 @@ SELECT b, char_length(b) FROM test2;
</sect3>
<sect3>
<title>time with time zone</title>
<title><type>time with time zone</type></title>
<para>
This type is defined by SQL92, but the definition exhibits
@ -1382,7 +1382,7 @@ SELECT b, char_length(b) FROM test2;
</sect3>
<sect3>
<title>timestamp</title>
<title><type>timestamp</type></title>
<indexterm>
<primary>timestamp</primary>
@ -1442,7 +1442,7 @@ January 8 04:05:06 1999 PST
</sect3>
<sect3>
<title>interval</title>
<title><type>interval</type></title>
<indexterm>
<primary>interval</primary>
@ -1664,7 +1664,7 @@ January 8 04:05:06 1999 PST
</listitem>
<listitem>
<para>
The <envar>PGDATESTYLE</envar> environment variable used by the frontend libpq
The <envar>PGDATESTYLE</envar> environment variable used by the frontend <application>libpq</application>
on session start-up.
</para>
</listitem>
@ -1753,13 +1753,13 @@ January 8 04:05:06 1999 PST
<itemizedlist spacing="compact" mark="bullet">
<listitem>
<para>
The TZ environment variable is used by the backend directly
The <envar>TZ</envar> environment variable is used by the backend directly
on postmaster start-up as the default time zone.
</para>
</listitem>
<listitem>
<para>
The PGTZ environment variable, if set at the client, is used by libpq
The <envar>PGTZ</envar> environment variable, if set at the client, is used by libpq
to send a <command>SET TIME ZONE</command> command to the backend upon
connection.
</para>
@ -1796,7 +1796,7 @@ January 8 04:05:06 1999 PST
<para>
If the runtime option <literal>AUSTRALIAN_TIMEZONES</literal> is set
then <literal>CST</literal> and <literal>EST</literal> refer to
Australian timezones, not American ones.
Australian time zones, not American ones.
</para>
</note>
</para>
@ -1939,49 +1939,49 @@ SELECT * FROM test1 WHERE a;
</thead>
<tbody>
<row>
<entry>point</entry>
<entry><type>point</type></entry>
<entry>16 bytes</entry>
<entry>(x,y)</entry>
<entry>Point in space</entry>
</row>
<row>
<entry>line</entry>
<entry><type>line</type></entry>
<entry>32 bytes</entry>
<entry>((x1,y1),(x2,y2))</entry>
<entry>Infinite line</entry>
</row>
<row>
<entry>lseg</entry>
<entry><type>lseg</type></entry>
<entry>32 bytes</entry>
<entry>((x1,y1),(x2,y2))</entry>
<entry>Finite line segment</entry>
</row>
<row>
<entry>box</entry>
<entry><type>box</type></entry>
<entry>32 bytes</entry>
<entry>((x1,y1),(x2,y2))</entry>
<entry>Rectangular box</entry>
</row>
<row>
<entry>path</entry>
<entry><type>path</type></entry>
<entry>4+32n bytes</entry>
<entry>((x1,y1),...)</entry>
<entry>Closed path (similar to polygon)</entry>
</row>
<row>
<entry>path</entry>
<entry><type>path</type></entry>
<entry>4+32n bytes</entry>
<entry>[(x1,y1),...]</entry>
<entry>Open path</entry>
</row>
<row>
<entry>polygon</entry>
<entry><type>polygon</type></entry>
<entry>4+32n bytes</entry>
<entry>((x1,y1),...)</entry>
<entry>Polygon (similar to closed path)</entry>
</row>
<row>
<entry>circle</entry>
<entry><type>circle</type></entry>
<entry>24 bytes</entry>
<entry><(x,y),r></entry>
<entry>Circle (center and radius)</entry>
@ -2296,21 +2296,21 @@ SELECT * FROM test1 WHERE a;
<tbody>
<row>
<entry>cidr</entry>
<entry><type>cidr</type></entry>
<entry>12 bytes</entry>
<entry>IP networks</entry>
<entry>valid IPv4 networks</entry>
</row>
<row>
<entry>inet</entry>
<entry><type>inet</type></entry>
<entry>12 bytes</entry>
<entry>IP hosts and networks</entry>
<entry>valid IPv4 hosts or networks</entry>
</row>
<row>
<entry>macaddr</entry>
<entry><type>macaddr</type></entry>
<entry>6 bytes</entry>
<entry>MAC addresses</entry>
<entry>customary formats</entry>
@ -2386,9 +2386,9 @@ SELECT * FROM test1 WHERE a;
<tgroup cols="3">
<thead>
<row>
<entry>CIDR Input</entry>
<entry>CIDR Displayed</entry>
<entry>abbrev(CIDR)</entry>
<entry><type>CIDR</type> Input</entry>
<entry><type>CIDR</type> Displayed</entry>
<entry><function>abbrev</function>(<type>CIDR</type>)</entry>
</row>
</thead>
<tbody>

4
doc/src/sgml/datetime.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.19 2001/06/18 19:05:11 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.20 2001/09/09 17:21:58 petere Exp $
Date/time details
-->
@ -225,7 +225,7 @@ Date/time details
<row>
<entry>DNT</entry>
<entry>+1:00 </entry>
<entry>Dansk Normal Tid</entry>
<entry><foreignphrase>Dansk Normal Tid</foreignphrase></entry>
</row>
<row>
<entry>FST</entry>

1072
doc/src/sgml/func.sgml
View File

File diff suppressed because it is too large Load Diff

10
doc/src/sgml/history.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
-->
<sect1 id="history">
@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
California at Berkeley. With over a decade of
development behind it, <productname>PostgreSQL</productname>
is the most advanced open-source database available anywhere,
offering multi-version concurrency control, supporting almost
offering multiversion concurrency control, supporting almost
all SQL constructs (including subselects, transactions, and
user-defined types and functions), and having a wide range of
language bindings available (including C, C++, Java, Perl, Tcl, and Python).
@ -72,7 +72,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
Finally,
<ulink url="http://www.illustra.com/">Illustra Information Technologies</ulink>
(since merged into
<ulink url="http://www.informix.com/">Informix</ulink>)
<ulink url="http://www.informix.com/"><productname>Informix</productname></ulink>)
picked up
the code and commercialized it.
<productname>Postgres</productname> became the primary data manager
@ -141,7 +141,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
<para>
A new front-end library, <filename>libpgtcl</filename>,
supported <acronym>Tcl</acronym>-based clients. A sample shell,
pgtclsh, provided new Tcl commands to interface
<command>pgtclsh</command>, provided new Tcl commands to interface
<application>tcl</application>
programs with the <productname>Postgres95</productname> backend.
</para>
@ -211,7 +211,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
<itemizedlist>
<listitem>
<para>
Table-level locking has been replaced with multi-version concurrency control,
Table-level locking has been replaced with multiversion concurrency control,
which allows readers to continue reading consistent data during writer activity
and enables hot backups from pg_dump while the database stays available for
queries.

6
doc/src/sgml/indices.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.22 2001/08/24 14:07:48 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.23 2001/09/09 17:21:59 petere Exp $ -->
<chapter id="indexes">
<title id="indexes-title">Indexes</title>
@ -571,7 +571,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
retrieving by that combination! However, if you want to make the retrieval
efficient, you'll have to resort to the means your
<acronym>RDBMS</acronym> provider gives you
- be it an index, my imaginary MEMSTORE command, or an intelligent
- be it an index, my imaginary <literal>MEMSTORE</literal> command, or an intelligent
<acronym>RDBMS</acronym>
that creates indexes without your knowledge based on the fact that you have
sent it many queries based on a specific combination of keys... (It learns
@ -629,7 +629,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
that involve deciding what predicate(s) match the workload/query in
some useful way. For those who are into database theory, the problems
are basically analogous to the corresponding materialized view
problems, albeit with different cost parameters and formulae. These
problems, albeit with different cost parameters and formulas. These
are, in the general case, hard problems for the standard ordinal
<acronym>SQL</acronym>
types; they're super-hard problems with black-box extension types,

6
doc/src/sgml/inherit.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
-->
<chapter id="inherit">
@ -37,7 +37,7 @@ CREATE TABLE capitals (
<note>
<para>
The inheritance hierarchy is a actually a directed acyclic graph.
The inheritance hierarchy is actually a directed acyclic graph.
</para>
</note>
</para>
@ -100,7 +100,7 @@ SELECT name, altitude
<para>
In some cases you may wish to know which table a particular tuple
originated from. There is a system column called
<quote>TABLEOID</quote> in each table which can tell you the
<structfield>TABLEOID</structfield> in each table which can tell you the
originating table:
<programlisting>

4
doc/src/sgml/legal.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.11 2001/09/09 17:21:59 petere Exp $
-->
<copyright>
@ -42,7 +42,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 peter
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS-IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTAINANCE, SUPPORT,
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
</para>

26
doc/src/sgml/manage.sgml
View File

@ -1,17 +1,15 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.13 2001/02/04 15:28:18 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
-->
<Chapter Id="manage">
<Title>Managing a Database</Title>
<Note>
<Para>
This section is currently a thinly disguised copy of the
Tutorial. Needs to be augmented.
<comment>
This section is currently a thinly disguised copy of the
Tutorial. Needs to be augmented.
- thomas 1998-01-12
</Para>
</Note>
</comment>
<Para>
Although the <FirstTerm>site administrator</FirstTerm> is responsible for overall management
@ -89,9 +87,9 @@ ERROR: CREATE DATABASE: Permission denied.
Alternate database locations are created and referenced by an environment variable
which gives the absolute path to the intended storage location.
This environment variable must have been defined before the postmaster was started
and the location it points to must be writable by the postgres administrator account.
and the location it points to must be writable by the administrator account.
Consult with the site administrator
regarding preconfigured alternate database locations.
regarding preconfigured alternative database locations.
Any valid environment variable name may be used to reference an alternate location,
although using variable names with a prefix of <envar>PGDATA</envar> is recommended
to avoid confusion
@ -101,7 +99,7 @@ ERROR: CREATE DATABASE: Permission denied.
<Note>
<Para>
In previous versions of <ProductName>Postgres</ProductName>,
it was also permissable to use an absolute path name to specify
it was also permissible to use an absolute path name to specify
an alternate storage location.
Although the environment variable style of specification
is to be preferred since it allows the site administrator more flexibility in
@ -181,7 +179,7 @@ enter, edit, and execute <Acronym>SQL</Acronym> commands.
</ListItem>
<ListItem>
<Para>
writing a C program using the LIBPQ subroutine
writing a C program using the <application>LIBPQ</application> subroutine
library. This allows you to submit <Acronym>SQL</Acronym> commands
from C and get answers and status messages back to
your program. This interface is discussed further
@ -213,7 +211,7 @@ mydb=>
</Para>
<Para>
This prompt indicates that psql is listening
This prompt indicates that <command>psql</command> is listening
to you and that you can type <Acronym>SQL</Acronym> queries into a
workspace maintained by the terminal monitor.
The <Application>psql</Application> program responds to escape codes that begin
@ -235,7 +233,7 @@ mydb=> \g
terminate your query with a semicolon, the "<literal>\g</literal>" is not
necessary.
<Application>psql</Application> will automatically process semicolon terminated queries.
To read queries from a file, say myFile, instead of
To read queries from a file, say <filename>myFile</filename>, instead of
entering them interactively, type:
<ProgramListing>
mydb=> \i fileName
@ -247,7 +245,7 @@ mydb=> \q
</ProgramListing>
and <Application>psql</Application> will quit and return you to your command
shell. (For more escape codes, type <Command>\?</Command> at the psql
shell. (For more escape codes, type <Command>\?</Command> at the <command>psql</command>
prompt.)
White space (i.e., spaces, tabs and newlines) may be
used freely in <Acronym>SQL</Acronym> queries. Single-line comments are denoted by

4
doc/src/sgml/mvcc.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.16 2001/07/09 22:18:33 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.17 2001/09/09 17:21:59 petere Exp $
-->
<chapter id="mvcc">
@ -593,7 +593,7 @@ ERROR: Can't serialize access due to concurrent update
<variablelist>
<varlistentry>
<term>
GiST and R-Tree indexes
<acronym>GiST</acronym> and R-Tree indexes
</term>
<listitem>
<para>

10
doc/src/sgml/notation.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.15 2001/09/09 17:21:59 petere Exp $
-->
<sect1 id="notation">
@ -38,10 +38,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe
<para>
Examples will show commands executed from various accounts and programs.
Commands executed from a Unix shell may be preceeded with a dollar sign
Commands executed from a Unix shell may be preceded with a dollar sign
(<quote><literal>$</literal></quote>). Commands executed from particular user
accounts such as root or postgres are specially flagged and explained.
<acronym>SQL</acronym> commands may be preceeded with
accounts such as <systemitem>root</> or <systemitem>postgres</> are specially flagged and explained.
<acronym>SQL</acronym> commands may be preceded with
<quote><literal>=&gt;</literal></quote>
or will have no leading prompt, depending on the context.
</para>
@ -49,7 +49,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe
<note>
<para>
The notation for
flagging commands is not universally consistant throughout the
flagging commands is not universally consistent throughout the
documentation set.
Please report problems to the documentation mailing list
<email>pgsql-docs@postgresql.org</email>.

42
doc/src/sgml/perform.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.7 2001/06/22 18:53:36 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.8 2001/09/09 17:21:59 petere Exp $
-->
<chapter id="performance-tips">
@ -109,9 +109,9 @@ Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
select * from pg_class where relname = 'tenk1';
</programlisting>
you'll find out that tenk1 has 233 disk
you will find out that <classname>tenk1</classname> has 233 disk
pages and 10000 tuples. So the cost is estimated at 233 page
reads, defined as 1.0 apiece, plus 10000 * cpu_tuple_cost which is
reads, defined as 1.0 apiece, plus 10000 * <varname>cpu_tuple_cost</varname> which is
currently 0.01 (try <command>show cpu_tuple_cost</command>).
</para>
@ -152,7 +152,7 @@ Index Scan using tenk1_unique1 on tenk1 (cost=0.00..173.32 rows=47 width=148)
and you will see that if we make the WHERE condition selective
enough, the planner will
eventually decide that an indexscan is cheaper than a sequential scan.
eventually decide that an index scan is cheaper than a sequential scan.
This plan will only have to visit 50 tuples because of the index,
so it wins despite the fact that each individual fetch is more expensive
than reading a whole disk page sequentially.
@ -169,7 +169,7 @@ NOTICE: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..173.44 rows=1 width=148)
</programlisting>
The added clause "stringu1 = 'xxx'" reduces the output-rows estimate,
The added clause <literal>stringu1 = 'xxx'</literal> reduces the output-rows estimate,
but not the cost because we still have to visit the same set of tuples.
</para>
@ -190,18 +190,18 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296)
</para>
<para>
In this nested-loop join, the outer scan is the same indexscan we had
In this nested-loop join, the outer scan is the same index scan we had
in the example before last, and so its cost and row count are the same
because we are applying the "unique1 &lt; 50" WHERE clause at that node.
The "t1.unique2 = t2.unique2" clause isn't relevant yet, so it doesn't
affect the outer scan's row count. For the inner scan, the
affect row count of the outer scan. For the inner scan, the unique2 value of the
current
outer-scan tuple's unique2 value is plugged into the inner indexscan
to produce an indexqual like
outer-scan tuple is plugged into the inner index scan
to produce an index qualification like
"t2.unique2 = <replaceable>constant</replaceable>". So we get the
same inner-scan plan and costs that we'd get from, say, "explain select
* from tenk2 where unique2 = 42". The loop node's costs are then set
on the basis of the outer scan's cost, plus one repetition of the
same inner-scan plan and costs that we'd get from, say, <literal>explain select
* from tenk2 where unique2 = 42</literal>. The costs of the loop node are then set
on the basis of the cost of the outer scan, plus one repetition of the
inner scan for each outer tuple (47 * 2.01, here), plus a little CPU
time for join processing.
</para>
@ -212,7 +212,7 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296)
in general you can have WHERE clauses that mention both relations and
so can only be applied at the join point, not to either input scan.
For example, if we added "WHERE ... AND t1.hundred &lt; t2.hundred",
that'd decrease the output row count of the join node, but not change
that would decrease the output row count of the join node, but not change
either input scan.
</para>
@ -237,13 +237,13 @@ Hash Join (cost=173.44..557.03 rows=47 width=296)
(cost=0.00..173.32 rows=47 width=148)
</programlisting>
This plan proposes to extract the 50 interesting rows of tenk1
using ye same olde indexscan, stash them into an in-memory hash table,
and then do a sequential scan of tenk2, probing into the hash table
for possible matches of "t1.unique2 = t2.unique2" at each tenk2 tuple.
The cost to read tenk1 and set up the hash table is entirely start-up
This plan proposes to extract the 50 interesting rows of <classname>tenk1</classname>
using ye same olde index scan, stash them into an in-memory hash table,
and then do a sequential scan of <classname>tenk2</classname>, probing into the hash table
for possible matches of "t1.unique2 = t2.unique2" at each <classname>tenk2</classname> tuple.
The cost to read <classname>tenk1</classname> and set up the hash table is entirely start-up
cost for the hash join, since we won't get any tuples out until we can
start reading tenk2. The total time estimate for the join also
start reading <classname>tenk2</classname>. The total time estimate for the join also
includes a hefty charge for CPU time to probe the hash table
10000 times. Note, however, that we are NOT charging 10000 times 173.32;
the hash table setup is only done once in this plan type.
@ -302,8 +302,8 @@ SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
annoyingly long time. When there are too many input tables, the
<productname>Postgres</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switchover threshold is
set by the GEQO_THRESHOLD run-time
through a limited number of possibilities. (The switch-over threshold is
set by the <varname>GEQO_THRESHOLD</varname> run-time
parameter described in the <citetitle>Administrator's Guide</citetitle>.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.

12
doc/src/sgml/problems.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 petere Exp $
-->
<sect1 id="bug-reporting">
@ -137,10 +137,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
query.
You are encouraged to
minimize the size of your example, but this is not absolutely necessary.
If the bug is reproduceable, we will find it either way.
If the bug is reproducible, we will find it either way.
</para>
<para>
If your application uses some other client interface, such as PHP, then
If your application uses some other client interface, such as <applicatioN>PHP</>, then
please try to isolate the offending queries. We will probably not set up a
web server to reproduce your problem. In any case remember to provide
the exact input files, do not guess that the problem happens for
@ -174,7 +174,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
The output you expected is very important to state. If you just write
"This command gives me that output." or "This is not
what I expected.", we might run it ourselves, scan the output, and
think it looks okay and is exactly what we expected. We should not have to
think it looks OK and is exactly what we expected. We should not have to
spend the time to decode the exact semantics behind your commands.
Especially refrain from merely saying that "This is not what SQL says/Oracle
does." Digging out the correct behavior from <acronym>SQL</acronym>
@ -188,7 +188,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
<para>
Any command line options and other start-up options, including concerned
environment variables or configuration files that you changed from the
default. Again, be exact. If you are using a pre-packaged
default. Again, be exact. If you are using a prepackaged
distribution that starts the database server at boot time, you should try
to find out how that is done.
</para>
@ -212,7 +212,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
old enough. You can also look into the <filename>README</filename> file
in the source directory or at the
name of your distribution file or package name.
If you run a pre-packaged version, such as RPMs, say so, including any
If you run a prepackaged version, such as RPMs, say so, including any
subversion the package may have. If you are talking about a CVS
snapshot, mention that, including its date and time.
</para>

42
doc/src/sgml/queries.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.8 2001/08/30 08:16:42 ishii Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.9 2001/09/09 17:21:59 petere Exp $ -->
<chapter id="queries">
<title>Queries</title>
@ -85,7 +85,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
A table reference may be a table name or a derived table such as a
subquery, a table join, or complex combinations of these. If more
than one table reference is listed in the FROM clause they are
CROSS JOINed (see below) to form the derived table that may then
cross-joined (see below) to form the derived table that may then
be subject to transformations by the WHERE, GROUP BY, and HAVING
clauses and is finally the result of the overall table expression.
</para>
@ -150,7 +150,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
</varlistentry>
<varlistentry>
<term>Qualified JOINs</term>
<term>Qualified joins</term>
<listitem>
<indexterm>
@ -166,7 +166,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
<para>
The words <token>INNER</token> and <token>OUTER</token> are
optional for all JOINs. <token>INNER</token> is the default;
optional for all joins. <token>INNER</token> is the default;
<token>LEFT</token>, <token>RIGHT</token>, and
<token>FULL</token> imply an OUTER JOIN.
</para>
@ -281,7 +281,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
<para>
Joins of all types can be chained together or nested: either
or both of <replaceable>T1</replaceable> and
<replaceable>T2</replaceable> may be JOINed tables. Parentheses
<replaceable>T2</replaceable> may be joined tables. Parentheses
may be used around JOIN clauses to control the join order. In the
absence of parentheses, JOIN clauses nest left-to-right.
</para>
@ -479,7 +479,7 @@ FROM a NATURAL JOIN b WHERE b.val &gt; 5
Which one of these you use is mainly a matter of style. The JOIN
syntax in the FROM clause is probably not as portable to other
products. For outer joins there is no choice in any case: they
must be done in the FROM clause. An outer join's ON/USING clause
must be done in the FROM clause. A ON/USING clause of an outer join
is <emphasis>not</> equivalent to a WHERE condition, because it
determines the addition of rows (for unmatched input rows) as well
as the removal of rows from the final result.
@ -505,16 +505,18 @@ FROM FDT WHERE
</programlisting>
<para>
In the examples above, FDT is the table derived in the FROM
clause. Rows that do not meet the search condition of the where
clause are eliminated from FDT. Notice the use of scalar
subqueries as value expressions. Just like
any other query, the subqueries can employ complex table
expressions. Notice how FDT is referenced in the subqueries.
Qualifying C1 as FDT.C1 is only necessary if C1 is also the name of a
column in the derived input table of the subquery. Qualifying the
column name adds clarity even when it is not needed. This shows how
the column naming scope of an outer query extends into its inner queries.
In the examples above, <literal>FDT</literal> is the table derived
in the FROM clause. Rows that do not meet the search condition of
the where clause are eliminated from
<literal>FDT</literal>. Notice the use of scalar subqueries as
value expressions. Just like any other query, the subqueries can
employ complex table expressions. Notice how
<literal>FDT</literal> is referenced in the subqueries.
Qualifying <literal>C1</> as <literal>FDT.C1</> is only necessary
if <literal>C1</> is also the name of a column in the derived
input table of the subquery. Qualifying the column name adds
clarity even when it is not needed. This shows how the column
naming scope of an outer query extends into its inner queries.
</para>
</sect2>
@ -569,7 +571,7 @@ SELECT pid, p.name, (sum(s.units) * p.price) AS sales
FROM products p LEFT JOIN sales s USING ( pid )
GROUP BY pid, p.name, p.price;
</programlisting>
In this example, the columns pid, p.name, and p.price must be in
In this example, the columns <literal>pid</literal>, <literal>p.name</literal>, and <literal>p.price</literal> must be in
the GROUP BY clause since they are referenced in the query select
list. The column s.units does not have to be in the GROUP BY list
since it is only used in an aggregate expression
@ -868,12 +870,12 @@ SELECT a, b FROM table1 ORDER BY a + b;
SELECT a AS b FROM table1 ORDER BY a;
</programlisting>
But these extensions do not work in queries involving UNION, INTERSECT,
or EXCEPT, and are not portable to other DBMSes.
or EXCEPT, and are not portable to other <acronym>DBMS</acronym>.
</para>
<para>
Each column specification may be followed by an optional ASC or
DESC to set the sort direction. ASC is default. Ascending order
Each column specification may be followed by an optional <token>ASC</token> or
<token>DESC</token> to set the sort direction. <token>ASC</token> is default. Ascending order
puts smaller values first, where <quote>smaller</quote> is defined
in terms of the <literal>&lt;</literal> operator. Similarly,
descending order is determined with the <literal>&gt;</literal>

38
doc/src/sgml/syntax.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.45 2001/08/26 21:17:12 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.46 2001/09/09 17:21:59 petere Exp $
-->
<chapter id="sql-syntax">
@ -462,7 +462,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<listitem>
<para>
"$" (dollar) cannot be a single-character operator, although it
can be part of a multi-character operator name.
can be part of a multiple-character operator name.
</para>
</listitem>
@ -476,7 +476,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<listitem>
<para>
A multi-character operator name cannot end in "+" or "-",
A multiple-character operator name cannot end in "+" or "-",
unless the name also contains at least one of these characters:
<literallayout>
~ ! @ # % ^ &amp; | ` ? $
@ -600,7 +600,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<para>
Alternatively, C-style block comments can be used:
<programlisting>
/* multi-line comment
/* multiline comment
* with nesting: /* nested block comment */
*/
</programlisting>
@ -634,7 +634,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<variablelist>
<varlistentry>
<term>oid</term>
<term><structfield>oid</></term>
<listitem>
<para>
<indexterm>
@ -649,20 +649,22 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry>
<varlistentry>
<term>tableoid</term>
<term><structfield>tableoid</></term>
<listitem>
<para>
The OID of the table containing this row. This attribute is
particularly handy for queries that select from inheritance
hierarchies, since without it, it's difficult to tell which
individual table a row came from. The tableoid can be joined
against the OID attribute of pg_class to obtain the table name.
individual table a row came from. The
<structfield>tableoid</structfield> can be joined against the
<structfield>oid</structfield> column of
<classname>pg_class</classname> to obtain the table name.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>xmin</term>
<term><structfield>xmin</></term>
<listitem>
<para>
The identity (transaction ID) of the inserting transaction for
@ -673,7 +675,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry>
<varlistentry>
<term>cmin</term>
<term><structfield>cmin</></term>
<listitem>
<para>
The command identifier (starting at zero) within the inserting
@ -683,7 +685,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry>
<varlistentry>
<term>xmax</term>
<term><structfield>xmax</></term>
<listitem>
<para>
The identity (transaction ID) of the deleting transaction,
@ -696,7 +698,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry>
<varlistentry>
<term>cmax</term>
<term><structfield>cmax</></term>
<listitem>
<para>
The command identifier within the deleting transaction, or zero.
@ -705,16 +707,16 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry>
<varlistentry>
<term>ctid</term>
<term><structfield>ctid</></term>
<listitem>
<para>
The tuple ID of the tuple within its table. This is a pair
(block number, tuple index within block) that identifies the
physical location of the tuple. Note that although the ctid
can be used to locate the tuple very quickly, a row's ctid
physical location of the tuple. Note that although the <structfield>ctid</structfield>
can be used to locate the tuple very quickly, a row's <structfield>ctid</structfield>
will change each time it is updated or moved by <command>VACUUM
FULL</>.
Therefore ctid is useless as a long-term row identifier.
Therefore <structfield>ctid</structfield> is useless as a long-term row identifier.
The OID, or even better a user-defined serial number, should
be used to identify logical rows.
</para>
@ -731,9 +733,9 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
Recommended practice when using OIDs for row identification is to create
a unique index on the OID column of each table for which the OID will be
used. Never assume that OIDs are unique across tables; use the
combination of tableoid and row OID if you need a database-wide
combination of <structfield>tableoid</> and row OID if you need a database-wide
identifier. (Future releases of Postgres are likely to use a separate
OID counter for each table, so that tableoid <emphasis>must</> be
OID counter for each table, so that <structfield>tableoid</> <emphasis>must</> be
included to arrive at a globally unique identifier.)
</para>

28
doc/src/sgml/typeconv.sgml
View File

@ -150,8 +150,8 @@ extended user-defined types to use these same features transparently.
<para>
An additional heuristic is provided in the parser to allow better guesses
at proper behavior for <acronym>SQL</acronym> standard types. There are
several basic <firstterm>type categories</firstterm> defined: boolean,
numeric, string, bitstring, datetime, timespan, geometric, network,
several basic <firstterm>type categories</firstterm> defined: <type>boolean</type>,
<type>numeric</type>, <type>string</type>, <type>bitstring</type>, <type>datetime</type>, <type>timespan</type>, <type>geometric</type>, <type>network</type>,
and user-defined. Each category, with the exception of user-defined, has
a <firstterm>preferred type</firstterm> which is preferentially selected
when there is ambiguity.
@ -273,7 +273,7 @@ If only one candidate remains, use it; else continue to the next step.
</step>
<step performance="required">
<para>
If any input arguments are "unknown", check the type categories accepted
If any input arguments are <quote>unknown</quote>, check the type categories accepted
at those argument positions by the remaining candidates. At each position,
select "string"
category if any candidate accepts that category (this bias towards string
@ -281,7 +281,7 @@ is appropriate since an unknown-type literal does look like a string).
Otherwise, if all the remaining candidates accept the same type category,
select that category; otherwise fail because
the correct choice cannot be deduced without more clues. Also note whether
any of the candidates accept a preferred datatype within the selected category.
any of the candidates accept a preferred data type within the selected category.
Now discard operator candidates that do not accept the selected type category;
furthermore, if any candidate accepts a preferred type at a given argument
position, discard candidates that accept non-preferred types for that
@ -391,7 +391,7 @@ tgl=> SELECT 'abc' || 'def' AS "Unspecified";
In this case there is no initial hint for which type to use, since no types
are specified in the query. So, the parser looks for all candidate operators
and finds that there are candidates accepting both string-category and
bitstring-category inputs. Since string category is preferred when available,
bit-string-category inputs. Since string category is preferred when available,
that category is selected, and then the
"preferred type" for strings, <type>text</type>, is used as the specific
type to resolve the unknown literals to.
@ -440,7 +440,7 @@ will try to oblige.
<step performance="required">
<para>
Check for an exact match in the pg_proc system catalog.
Check for an exact match in the <classname>pg_proc</classname> system catalog.
(Cases involving <type>unknown</type> will never find a match at
this step.)
</para></step>
@ -491,7 +491,7 @@ is appropriate since an unknown-type literal does look like a string).
Otherwise, if all the remaining candidates accept the same type category,
select that category; otherwise fail because
the correct choice cannot be deduced without more clues. Also note whether
any of the candidates accept a preferred datatype within the selected category.
any of the candidates accept a preferred data type within the selected category.
Now discard operator candidates that do not accept the selected type category;
furthermore, if any candidate accepts a preferred type at a given argument
position, discard candidates that accept non-preferred types for that
@ -512,10 +512,10 @@ then fail.
If no best match could be identified, see whether the function call appears
to be a trivial type coercion request. This happens if the function call
has just one argument and the function name is the same as the (internal)
name of some datatype. Furthermore, the function argument must be either
name of some data type. Furthermore, the function argument must be either
an unknown-type literal or a type that is binary-compatible with the named
datatype. When these conditions are met, the function argument is coerced
to the named datatype.
data type. When these conditions are met, the function argument is coerced
to the named data type.
</para>
</step>
</procedure>
@ -527,7 +527,7 @@ to the named datatype.
<title>Factorial Function</title>
<para>
There is only one factorial function defined in the pg_proc catalog.
There is only one factorial function defined in the <classname>pg_proc</classname> catalog.
So the following query automatically converts the <type>int2</type> argument
to <type>int4</type>:
@ -554,7 +554,7 @@ tgl=> select int4fac(int4(int2 '4'));
<title>Substring Function</title>
<para>
There are two <function>substr</function> functions declared in pg_proc. However,
There are two <function>substr</function> functions declared in <classname>pg_proc</classname>. However,
only one takes two arguments, of types <type>text</type> and <type>int4</type>.
</para>
@ -679,8 +679,8 @@ tgl=> SELECT * FROM vv;
What's really happened here is that the two unknown literals are resolved
to text by default, allowing the <literal>||</literal> operator to be
resolved as text concatenation. Then the text result of the operator
is coerced to varchar to match the target column type. (But, since the
parser knows that text and varchar are binary-compatible, this coercion
is coerced to <type>varchar</type> to match the target column type. (But, since the
parser knows that text and <type>varchar</type> are binary-compatible, this coercion
is implicit and does not insert any real function call.) Finally, the
sizing function <literal>varchar(varchar,int4)</literal> is found in the system
catalogs and applied to the operator's result and the stored column length.