Commit 2b6a35f7 authored by Thomas G. Lockhart's avatar Thomas G. Lockhart

Fix several <ulink> tags which refer to e-mail addresses

 but were missing the "mailto:" prefix.
Fix typo.
Thanks to Neil Conway <nconway@klamath.dyndns.org> for the heads-up.
parent f9b2f9bb
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.32 2000/07/29 18:45:51 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.33 2000/08/23 05:59:01 thomas Exp $
--> -->
<chapter id="datatype"> <chapter id="datatype">
...@@ -594,7 +594,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl ...@@ -594,7 +594,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
<entry>12 bytes</entry> <entry>12 bytes</entry>
<entry>-178000000 years</entry> <entry>-178000000 years</entry>
<entry>178000000 years</entry> <entry>178000000 years</entry>
<entry>1 mircosecond</entry> <entry>1 microsecond</entry>
</row> </row>
<row> <row>
<entry><type>date</type></entry> <entry><type>date</type></entry>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.10 2000/05/02 20:36:21 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.11 2000/08/23 05:59:01 thomas Exp $
Date/time details Date/time details
--> -->
...@@ -629,7 +629,7 @@ Date/time details ...@@ -629,7 +629,7 @@ Date/time details
<note> <note>
<para> <para>
Contributed by Contributed by
<ulink url="jose@sferacarta.com">José Soares</ulink>. <ulink url="mailto:jose@sferacarta.com">José Soares</ulink>.
</para> </para>
</note> </note>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.14 2000/05/02 20:01:51 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.15 2000/08/23 05:59:01 thomas Exp $
--> -->
<chapter> <chapter>
...@@ -32,8 +32,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.14 2000/05/02 20:01:51 thomas ...@@ -32,8 +32,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.14 2000/05/02 20:01:51 thomas
This describes an embedded <acronym>SQL</acronym> in <acronym>C</acronym> This describes an embedded <acronym>SQL</acronym> in <acronym>C</acronym>
package for <productname>Postgres</productname>. package for <productname>Postgres</productname>.
It is written by <ulink url="linus@epact.se">Linus Tolke</ulink> It is written by <ulink url="mailto:linus@epact.se">Linus Tolke</ulink>
and <ulink url="meskes@debian.org">Michael Meskes</ulink>. and <ulink url="mailto:meskes@debian.org">Michael Meskes</ulink>.
<note> <note>
<para> <para>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.10 2000/06/28 03:30:53 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.11 2000/08/23 05:59:02 thomas Exp $
Genetic Optimizer Genetic Optimizer
--> -->
<Chapter Id="geqo"> <chapter id="geqo">
<DocInfo> <docinfo>
<Author> <author>
<FirstName>Martin</FirstName> <firstname>Martin</firstname>
<SurName>Utesch</SurName> <surname>Utesch</surname>
<Affiliation> <affiliation>
<Orgname> <orgname>
University of Mining and Technology University of Mining and Technology
</Orgname> </orgname>
<Orgdiv> <orgdiv>
Institute of Automatic Control Institute of Automatic Control
</Orgdiv> </orgdiv>
<Address> <address>
<City> <city>
Freiberg Freiberg
</City> </city>
<Country> <country>
Germany Germany
</Country> </country>
</Address> </address>
</Affiliation> </affiliation>
</Author> </author>
<Date>1997-10-02</Date> <date>1997-10-02</date>
</DocInfo> </docinfo>
<Title>Genetic Query Optimization in Database Systems</Title> <title>Genetic Query Optimization in Database Systems</title>
<Para> <para>
<Note> <note>
<Title>Author</Title> <title>Author</title>
<Para> <para>
Written by <ULink url="utesch@aut.tu-freiberg.de">Martin Utesch</ULink> Written by <ulink url="mailto:utesch@aut.tu-freiberg.de">Martin Utesch</ulink>
for the Institute of Automatic Control at the University of Mining and Technology in Freiberg, Germany. for the Institute of Automatic Control at the University of Mining and Technology in Freiberg, Germany.
</Para> </para>
</Note> </note>
</para> </para>
<Sect1> <sect1>
<Title>Query Handling as a Complex Optimization Problem</Title> <title>Query Handling as a Complex Optimization Problem</title>
<Para> <para>
Among all relational operators the most difficult one to process and Among all relational operators the most difficult one to process and
optimize is the <FirstTerm>join</FirstTerm>. The number of alternative plans to answer a query optimize is the <firstterm>join</firstterm>. The number of alternative plans to answer a query
grows exponentially with the number of <Command>join</Command>s included in it. Further grows exponentially with the number of <command>join</command>s included in it. Further
optimization effort is caused by the support of a variety of <FirstTerm>join methods</FirstTerm> optimization effort is caused by the support of a variety of
(e.g., nested loop, index scan, merge join in <ProductName>Postgres</ProductName>) to <firstterm>join methods</firstterm>
process individual <Command>join</Command>s and a diversity of <FirstTerm>indices</FirstTerm> (e.g., r-tree, (e.g., nested loop, index scan, merge join in <productname>Postgres</productname>) to
b-tree, hash in <ProductName>Postgres</ProductName>) as access paths for relations. process individual <command>join</command>s and a diversity of
</para> <firstterm>indices</firstterm> (e.g., r-tree,
b-tree, hash in <productname>Postgres</productname>) as access paths for relations.
<Para> </para>
The current <ProductName>Postgres</ProductName> optimizer implementation performs a <FirstTerm>near-
exhaustive search</FirstTerm> over the space of alternative strategies. This query <para>
optimization technique is inadequate to support database application The current <productname>Postgres</productname> optimizer
domains that involve the need for extensive queries, such as artificial implementation performs a <firstterm>near-
intelligence. exhaustive search</firstterm> over the space of alternative strategies. This query
</para> optimization technique is inadequate to support database application
domains that involve the need for extensive queries, such as artificial
<Para> intelligence.
The Institute of Automatic Control at the University of Mining and </para>
Technology, in Freiberg, Germany, encountered the described problems as its
folks wanted to take the <ProductName>Postgres</ProductName> DBMS as the backend for a decision <para>
support knowledge based system for the maintenance of an electrical The Institute of Automatic Control at the University of Mining and
power grid. The DBMS needed to handle large <Command>join</Command> queries for the Technology, in Freiberg, Germany, encountered the described problems as its
inference machine of the knowledge based system. folks wanted to take the <productname>Postgres</productname> DBMS as the backend for a decision
</para> support knowledge based system for the maintenance of an electrical
power grid. The DBMS needed to handle large <command>join</command> queries for the
<Para> inference machine of the knowledge based system.
Performance difficulties within exploring the space of possible query </para>
plans arose the demand for a new optimization technique being developed.
</para> <para>
Performance difficulties within exploring the space of possible query
<Para> plans arose the demand for a new optimization technique being developed.
In the following we propose the implementation of a <FirstTerm>Genetic Algorithm</FirstTerm> </para>
as an option for the database query optimization problem.
</para> <para>
</sect1> In the following we propose the implementation of a <firstterm>Genetic Algorithm</firstterm>
as an option for the database query optimization problem.
<Sect1> </para>
<Title>Genetic Algorithms (<Acronym>GA</Acronym>)</Title> </sect1>
<Para> <sect1>
The <Acronym>GA</Acronym> is a heuristic optimization method which operates through <title>Genetic Algorithms (<acronym>GA</acronym>)</title>
determined, randomized search. The set of possible solutions for the
optimization problem is considered as a <FirstTerm>population</FirstTerm> of <FirstTerm>individuals</FirstTerm>. <para>
The degree of adaption of an individual to its environment is specified The <acronym>GA</acronym> is a heuristic optimization method which operates through
by its <FirstTerm>fitness</FirstTerm>. determined, randomized search. The set of possible solutions for the
</para> optimization problem is considered as a
<firstterm>erm>popula</firstterm>erm> of <firstterm>individuals</firstterm>.
<Para> The degree of adaption of an individual to its environment is specified
The coordinates of an individual in the search space are represented by its <firstterm>fitness</firstterm>.
by <FirstTerm>chromosomes</FirstTerm>, in essence a set of character strings. A <FirstTerm>gene</FirstTerm> is a </para>
subsection of a chromosome which encodes the value of a single parameter
being optimized. Typical encodings for a gene could be <FirstTerm>binary</FirstTerm> or <para>
<FirstTerm>integer</FirstTerm>. The coordinates of an individual in the search space are represented
</para> by <firstterm>chromosomes</firstterm>, in essence a set of character
strings. A <firstterm>gene</firstterm> is a
<Para> subsection of a chromosome which encodes the value of a single parameter
Through simulation of the evolutionary operations <FirstTerm>recombination</FirstTerm>, being optimized. Typical encodings for a gene could be <firstterm>binary</firstterm> or
<FirstTerm>mutation</FirstTerm>, and <FirstTerm>selection</FirstTerm> new generations of search points are found <firstterm>integer</firstterm>.
that show a higher average fitness than their ancestors. </para>
</para>
<para>
<Para> Through simulation of the evolutionary operations <firstterm>recombination</firstterm>,
According to the "comp.ai.genetic" <Acronym>FAQ</Acronym> it cannot be stressed too <firstterm>mutation</firstterm>, and
strongly that a <Acronym>GA</Acronym> is not a pure random search for a solution to a <firstterm>selection</firstterm> new generations of search points are found
problem. A <Acronym>GA</Acronym> uses stochastic processes, but the result is distinctly that show a higher average fitness than their ancestors.
non-random (better than random). </para>
<ProgramListing> <para>
Structured Diagram of a <Acronym>GA</Acronym>: According to the "comp.ai.genetic" <acronym>FAQ</acronym> it cannot be stressed too
strongly that a <acronym>GA</acronym> is not a pure random search for a solution to a
problem. A <acronym>GA</acronym> uses stochastic processes, but the result is distinctly
non-random (better than random).
<programlisting>
Structured Diagram of a <acronym>GA</acronym>:
--------------------------- ---------------------------
P(t) generation of ancestors at a time t P(t) generation of ancestors at a time t
...@@ -140,229 +146,235 @@ P''(t) generation of descendants at a time t ...@@ -140,229 +146,235 @@ P''(t) generation of descendants at a time t
| +-------------------------------------+ | +-------------------------------------+
| | t := t + 1 | | | t := t + 1 |
+===+=====================================+ +===+=====================================+
</ProgramListing> </programlisting>
</para> </para>
</sect1> </sect1>
<Sect1> <sect1>
<Title>Genetic Query Optimization (<Acronym>GEQO</Acronym>) in Postgres</Title> <title>Genetic Query Optimization (<acronym>GEQO</acronym>) in Postgres</title>
<Para> <para>
The <Acronym>GEQO</Acronym> module is intended for the solution of the query The <acronym>GEQO</acronym> module is intended for the solution of the query
optimization problem similar to a traveling salesman problem (<Acronym>TSP</Acronym>). optimization problem similar to a traveling salesman problem (<acronym>TSP</acronym>).
Possible query plans are encoded as integer strings. Each string Possible query plans are encoded as integer strings. Each string
represents the <Command>join</Command> order from one relation of the query to the next. represents the <command>join</command> order from one relation of the query to the next.
E. g., the query tree E. g., the query tree
<ProgramListing> <programlisting>
/\ /\
/\ 2 /\ 2
/\ 3 /\ 3
4 1 4 1
</ProgramListing> </programlisting>
is encoded by the integer string '4-1-3-2', is encoded by the integer string '4-1-3-2',
which means, first join relation '4' and '1', then '3', and which means, first join relation '4' and '1', then '3', and
then '2', where 1, 2, 3, 4 are relids in <ProductName>Postgres</ProductName>. then '2', where 1, 2, 3, 4 are relids in <productname>Postgres</productname>.
</para> </para>
<Para> <para>
Parts of the <Acronym>GEQO</Acronym> module are adapted from D. Whitley's Genitor Parts of the <acronym>GEQO</acronym> module are adapted from D. Whitley's Genitor
algorithm. algorithm.
</para> </para>
<Para> <para>
Specific characteristics of the <Acronym>GEQO</Acronym> implementation in <ProductName>Postgres</ProductName> Specific characteristics of the <acronym>GEQO</acronym>
are: implementation in <productname>Postgres</productname>
are:
<ItemizedList Mark="bullet" Spacing="compact">
<ListItem> <itemizedlist spacing="compact" mark="bullet">
<Para> <listitem>
Usage of a <FirstTerm>steady state</FirstTerm> <Acronym>GA</Acronym> (replacement of the least fit <para>
individuals in a population, not whole-generational replacement) Usage of a <firstterm>steady state</firstterm> <acronym>GA</acronym> (replacement of the least fit
allows fast convergence towards improved query plans. This is individuals in a population, not whole-generational replacement)
essential for query handling with reasonable time; allows fast convergence towards improved query plans. This is
</Para> essential for query handling with reasonable time;
</ListItem> </para>
</listitem>
<ListItem>
<Para> <listitem>
Usage of <FirstTerm>edge recombination crossover</FirstTerm> which is especially suited <para>
to keep edge losses low for the solution of the <Acronym>TSP</Acronym> by means of a <Acronym>GA</Acronym>; Usage of <firstterm>edge recombination crossover</firstterm> which is especially suited
</Para> to keep edge losses low for the solution of the
</ListItem> <acronym>cro</acronym>cronym> by means of a <acronym>GA</acronym>;
</para>
<ListItem> </listitem>
<Para>
Mutation as genetic operator is deprecated so that no repair <listitem>
mechanisms are needed to generate legal <Acronym>TSP</Acronym> tours. <para>
</Para> Mutation as genetic operator is deprecated so that no repair
</ListItem> mechanisms are needed to generate legal <acronym>TSP</acronym> tours.
</ItemizedList> </para>
</para> </listitem>
</itemizedlist>
<Para> </para>
The <Acronym>GEQO</Acronym> module gives the following benefits to the <ProductName>Postgres</ProductName> DBMS
compared to the <ProductName>Postgres</ProductName> query optimizer implementation: <para>
The <acronym>GEQO</acronym> module gives the following benefits to
<ItemizedList Mark="bullet" Spacing="compact"> the <productname>Postgres</productname> DBMS
<ListItem> compared to the <productname>Postgres</productname> query optimizer implementation:
<Para>
Handling of large <Command>join</Command> queries through non-exhaustive search; <itemizedlist spacing="compact" mark="bullet">
</Para> <listitem>
</ListItem> <para>
Handling of large <command>join</command> queries through non-exhaustive search;
<ListItem> </para>
<Para> </listitem>
Improved cost size approximation of query plans since no longer
plan merging is needed (the <Acronym>GEQO</Acronym> module evaluates the cost for a <listitem>
query plan as an individual). <para>
</Para> Improved cost size approximation of query plans since no longer
</ListItem> plan merging is needed (the <acronym>GEQO</acronym> module evaluates the cost for a
</ItemizedList> query plan as an individual).
</para> </para>
</listitem>
</Sect1> </itemizedlist>
</para>
<Sect1>
<Title>Future Implementation Tasks for <ProductName>Postgres</ProductName> <Acronym>GEQO</Acronym></Title> </sect1>
<Sect2> <sect1>
<Title>Basic Improvements</Title> <title>Future Implementation Tasks for
<productname>ame>Post</productname>ame> <acronym>GEQO</acronym></title>
<Sect3>
<Title>Improve genetic algorithm parameter settings</Title> <sect2>
<title>Basic Improvements</title>
<Para>
In file <FileName>backend/optimizer/geqo/geqo_params.c</FileName>, routines <sect3>
<Function>gimme_pool_size</Function> and <Function>gimme_number_generations</Function>, <title>Improve genetic algorithm parameter settings</title>
we have to find a compromise for the parameter settings
to satisfy two competing demands: <para>
<ItemizedList Spacing="compact"> In file <filename>backend/optimizer/geqo/geqo_params.c</filename>, routines
<ListItem> <function>gimme_pool_size</function> and <function>gimme_number_generations</function>,
<Para> we have to find a compromise for the parameter settings
Optimality of the query plan to satisfy two competing demands:
</Para> <itemizedlist spacing="compact">
</ListItem> <listitem>
<ListItem> <para>
<Para> Optimality of the query plan
Computing time </para>
</Para> </listitem>
</ListItem> <listitem>
</ItemizedList> <para>
</para> Computing time
</sect3> </para>
</listitem>
<Sect3> </itemizedlist>
<Title>Find better solution for integer overflow</Title> </para>
</sect3>
<Para>
In file <FileName>backend/optimizer/geqo/geqo_eval.c</FileName>, routine <sect3>
<Function>geqo_joinrel_size</Function>, <title>Find better solution for integer overflow</title>
the present hack for MAXINT overflow is to set the <ProductName>Postgres</ProductName> integer
value of <StructField>rel->size</StructField> to its logarithm. <para>
Modifications of <StructName>Rel</StructName> in <FileName>backend/nodes/relation.h</FileName> will In file <filename>backend/optimizer/geqo/geqo_eval.c</filename>, routine
surely have severe impacts on the whole <ProductName>Postgres</ProductName> implementation. <function>geqo_joinrel_size</function>,
</para> the present hack for MAXINT overflow is to set the <productname>Postgres</productname> integer
</sect3> value of <structfield>rel->size</structfield> to its logarithm.
Modifications of <structname>Rel</structname> in <filename>backend/nodes/relation.h</filename> will
<Sect3> surely have severe impacts on the whole <productname>Postgres</productname> implementation.
<Title>Find solution for exhausted memory</Title> </para>
</sect3>
<Para>
Memory exhaustion may occur with more than 10 relations involved in a query. <sect3>
In file <FileName>backend/optimizer/geqo/geqo_eval.c</FileName>, routine <title>Find solution for exhausted memory</title>
<Function>gimme_tree</Function> is recursively called.
Maybe I forgot something to be freed correctly, but I dunno what. <para>
Of course the <StructName>rel</StructName> data structure of the <Command>join</Command> keeps growing and Memory exhaustion may occur with more than 10 relations involved in a query.
growing the more relations are packed into it. In file <filename>backend/optimizer/geqo/geqo_eval.c</filename>, routine
Suggestions are welcome :-( <function>gimme_tree</function> is recursively called.
</para> Maybe I forgot something to be freed correctly, but I dunno what.
</sect3> Of course the <structname>rel</structname> data structure of the
</sect2> <command>join</command> keeps growing and
growing the more relations are packed into it.
Suggestions are welcome :-(
<BIBLIOGRAPHY Id="geqo-biblio"> </para>
<TITLE> </sect3>
References </sect2>
</TITLE>
<PARA>Reference information for <Acronym>GEQ</Acronym> algorithms.
</PARA> <bibliography id="geqo-biblio">
<BIBLIOENTRY> <title>
References
<BOOKBIBLIO> </title>
<TITLE> <para>Reference information for <acronym>GEQ</acronym> algorithms.
The Hitch-Hiker's Guide to Evolutionary Computation </para>
</TITLE> <biblioentry>
<AUTHORGROUP>
<AUTHOR> <bookbiblio>
<FIRSTNAME>J&ouml;rg</FIRSTNAME> <title>
<SURNAME>Heitk&ouml;tter</SURNAME> The Hitch-Hiker's Guide to Evolutionary Computation
</AUTHOR> </title>
<AUTHOR> <authorgroup>
<FIRSTNAME>David</FIRSTNAME> <author>
<SURNAME>Beasley</SURNAME> <firstname>J&ouml;rg</firstname>
</AUTHOR> <surname>Heitk&ouml;tter</surname>
</AUTHORGROUP> </author>
<PUBLISHER> <author>
<PUBLISHERNAME> <firstname>David</firstname>
InterNet resource <surname>Beasley</surname>
</PUBLISHERNAME> </author>
</PUBLISHER> </authorgroup>
<ABSTRACT> <publisher>
<Para> <publishername>
FAQ in <ULink url="news://comp.ai.genetic">comp.ai.genetic</ULink> InterNet resource
is available at <ULink url="ftp://ftp.Germany.EU.net/pub/research/softcomp/EC/Welcome.html">Encore</ULink>. </publishername>
</Para> </publisher>
</ABSTRACT> <abstract>
</BOOKBIBLIO> <para>
FAQ in <ulink url="news://comp.ai.genetic">comp.ai.genetic</ulink>
<BOOKBIBLIO> is available at <ulink
<TITLE> url="ftp://ftp.Germany.EU.net/pub/research/softcomp/EC/Welcome.html">Encore</ulink>.
The Design and Implementation of the Postgres Query Optimizer </para>
</TITLE> </abstract>
<AUTHORGROUP> </bookbiblio>
<AUTHOR>
<FIRSTNAME>Z.</FIRSTNAME> <bookbiblio>
<SURNAME>Fong</SURNAME> <title>
</AUTHOR> The Design and Implementation of the Postgres Query Optimizer
</AUTHORGROUP> </title>
<PUBLISHER> <authorgroup>
<PUBLISHERNAME> <author>
University of California, Berkeley Computer Science Department <firstname>Z.</firstname>
</PUBLISHERNAME> <surname>Fong</surname>
</PUBLISHER> </author>
<ABSTRACT> </authorgroup>
<Para> <publisher>
File <FileName>planner/Report.ps</FileName> in the 'postgres-papers' distribution. <publishername>
</Para> University of California, Berkeley Computer Science Department
</ABSTRACT> </publishername>
</BOOKBIBLIO> </publisher>
<abstract>
<BOOKBIBLIO> <para>
<TITLE> File <filename>planner/Report.ps</filename> in the 'postgres-papers' distribution.
Fundamentals of Database Systems </para>
</TITLE> </abstract>
<AUTHORGROUP> </bookbiblio>
<AUTHOR>
<FIRSTNAME>R.</FIRSTNAME> <bookbiblio>
<SURNAME>Elmasri</SURNAME> <title>
</AUTHOR> Fundamentals of Database Systems
<AUTHOR> </title>
<FIRSTNAME>S.</FIRSTNAME> <authorgroup>
<SURNAME>Navathe</SURNAME> <author>
</AUTHOR> <firstname>R.</firstname>
</AUTHORGROUP> <surname>Elmasri</surname>
<PUBLISHER> </author>
<PUBLISHERNAME> <author>
The Benjamin/Cummings Pub., Inc. <firstname>S.</firstname>
</PUBLISHERNAME> <surname>Navathe</surname>
</PUBLISHER> </author>
</BOOKBIBLIO> </authorgroup>
<publisher>
</BIBLIOENTRY> <publishername>
</BIBLIOGRAPHY> The Benjamin/Cummings Pub., Inc.
</publishername>
</sect1> </publisher>
</Chapter> </bookbiblio>
</biblioentry>
</bibliography>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file <!-- Keep this comment at the end of the file
Local variables: Local variables:
......
...@@ -163,7 +163,7 @@ SELECT am.amname AS acc_name, ...@@ -163,7 +163,7 @@ SELECT am.amname AS acc_name,
<title>Author</title> <title>Author</title>
<para> <para>
Written by Written by
<ulink url="herouth@oumail.openu.ac.il">Herouth Maoz</ulink> <ulink url="mailto:herouth@oumail.openu.ac.il">Herouth Maoz</ulink>
This originally appeared on the User's Mailing List on 1998-03-02 This originally appeared on the User's Mailing List on 1998-03-02
in response to the question: in response to the question:
"What is the difference between PRIMARY KEY and UNIQUE constraints?". "What is the difference between PRIMARY KEY and UNIQUE constraints?".
...@@ -328,7 +328,7 @@ CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt; ...@@ -328,7 +328,7 @@ CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt;
<title>Author</title> <title>Author</title>
<para> <para>
This is from a reply to a question on the e-mail list This is from a reply to a question on the e-mail list
by <ulink url="aoki@CS.Berkeley.EDU">Paul M. Aoki</ulink> by <ulink url="mailto:aoki@CS.Berkeley.EDU">Paul M. Aoki</ulink>
on 1998-08-11. on 1998-08-11.
<!-- <!--
Paul M. Aoki | University of California at Berkeley Paul M. Aoki | University of California at Berkeley
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.10 2000/03/31 03:27:40 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.11 2000/08/23 05:59:02 thomas Exp $
--> -->
<chapter id="jdbc"> <chapter id="jdbc">
...@@ -9,7 +9,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.10 2000/03/31 03:27:40 ...@@ -9,7 +9,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.10 2000/03/31 03:27:40
<note> <note>
<title>Author</title> <title>Author</title>
<para> <para>
Written by <ulink url="peter@retep.org.uk">Peter T. Mount</ulink>, the Written by <ulink url="mailto:peter@retep.org.uk">Peter T. Mount</ulink>, the
author of the <acronym>JDBC</acronym> driver. author of the <acronym>JDBC</acronym> driver.
</para> </para>
</note> </note>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/keys.sgml,v 1.3 1998/12/29 02:24:16 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/keys.sgml,v 1.4 2000/08/23 05:59:02 thomas Exp $
Indices and Keys Indices and Keys
$Log: keys.sgml,v $ $Log: keys.sgml,v $
Revision 1.4 2000/08/23 05:59:02 thomas
Fix several <ulink> tags which refer to e-mail addresses
but were missing the "mailto:" prefix.
Fix typo.
Thanks to Neil Conway <nconway@klamath.dyndns.org> for the heads-up.
Revision 1.3 1998/12/29 02:24:16 thomas Revision 1.3 1998/12/29 02:24:16 thomas
Clean up to ensure tag completion as required by the newest versions Clean up to ensure tag completion as required by the newest versions
of Norm's Modular Style Sheets and jade/docbook. of Norm's Modular Style Sheets and jade/docbook.
...@@ -18,37 +24,37 @@ Will go into the User's Guide. ...@@ -18,37 +24,37 @@ Will go into the User's Guide.
--> -->
<chapter id="keys"> <chapter>
<docinfo> <docinfo>
<authorgroup> <authorgroup>
<author> <author>
<firstname>Herouth</firstname> <firstname>Herouth</firstname>
<surname>Maoz</surname> <surname>Maoz</surname>
</author> </author>
</authorgroup> </authorgroup>
<date>1998-03-02</date> <date>1998-03-02</date>
</docinfo> </docinfo>
<Title>Indices and Keys</Title> <title>Indices and Keys</title>
<Note> <note>
<Title>Author</Title> <title>Author</title>
<Para> <para>
Written by Written by
<ULink url="herouth@oumail.openu.ac.il">Herouth Maoz</ULink> <ulink url="mailto:herouth@oumail.openu.ac.il">Herouth Maoz</ulink>
</Para> </para>
</Note> </note>
<Note> <note>
<Title>Editor's Note</Title> <title>Editor's Note</title>
<Para> <para>
This originally appeared on the mailing list This originally appeared on the mailing list
in response to the question: in response to the question:
"What is the difference between PRIMARY KEY and UNIQUE constraints?". "What is the difference between PRIMARY KEY and UNIQUE constraints?".
</Para> </para>
</Note> </note>
<ProgramListing> <programlisting>
Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
What's the difference between: What's the difference between:
...@@ -59,125 +65,143 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE ...@@ -59,125 +65,143 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
- Is this an alias? - Is this an alias?
- If PRIMARY KEY is already unique, then why - If PRIMARY KEY is already unique, then why
is there another kind of key named UNIQUE? is there another kind of key named UNIQUE?
</ProgramListing> </programlisting>
<Para> <para>
A primary key is the field(s) used to identify a specific row. For example, A primary key is the field(s) used to identify a specific row. For example,
Social Security numbers identifying a person. Social Security numbers identifying a person.
</Para> </para>
<Para> <para>
A simply UNIQUE combination of fields has nothing to do with identifying A simply UNIQUE combination of fields has nothing to do with identifying
the row. It's simply an integrity constraint. For example, I have the row. It's simply an integrity constraint. For example, I have
collections of links. Each collection is identified by a unique number, collections of links. Each collection is identified by a unique number,
which is the primary key. This key is used in relations. which is the primary key. This key is used in relations.
</Para> </para>
<Para> <para>
However, my application requires that each collection will also have a However, my application requires that each collection will also have a
unique name. Why? So that a human being who wants to modify a collection unique name. Why? So that a human being who wants to modify a collection
will be able to identify it. It's much harder to know, if you have two will be able to identify it. It's much harder to know, if you have two
collections named "Life Science", the the one tagged 24433 is the one you collections named "Life Science", the the one tagged 24433 is the one you
need, and the one tagged 29882 is not. need, and the one tagged 29882 is not.
</Para> </para>
<Para> <para>
So, the user selects the collection by its name. We therefore make sure, So, the user selects the collection by its name. We therefore make sure,
withing the database, that names are unique. However, no other table in the withing the database, that names are unique. However, no other table in the
database relates to the collections table by the collection Name. That database relates to the collections table by the collection Name. That
would be very inefficient. would be very inefficient.
</Para> </para>
<Para> <para>
Moreover, despite being unique, the collection name does not actually Moreover, despite being unique, the collection name does not actually
define the collection! For example, if somebody decided to change the name define the collection! For example, if somebody decided to change the name
of the collection from "Life Science" to "Biology", it will still be the of the collection from "Life Science" to "Biology", it will still be the
same collection, only with a different name. As long as the name is unique, same collection, only with a different name. As long as the name is unique,
that's OK. that's OK.
</Para> </para>
<Para> <para>
So: So:
<itemizedlist> <itemizedlist>
<ListItem> <listitem>
<Para> <para>
Primary key: Primary key:
<itemizedList Mark="bullet" Spacing="compact"> <itemizedlist>
<ListItem> <listitem>
<Para> <para>
Is used for identifying the row and relating to it. Is used for identifying the row and relating to it.
</Para> </para>
</ListItem> </listitem>
<ListItem> <listitem>
<Para> <para>
Is impossible (or hard) to update. Is impossible (or hard) to update.
</Para> </para>
</ListItem> </listitem>
<ListItem> <listitem>
<Para> <para>
Should not allow NULLs. Should not allow NULLs.
</Para> </para>
</ListItem> </listitem>
</itemizedlist> </itemizedlist>
</para> </para>
</listitem> </listitem>
<ListItem> <listitem>
<Para> <para>
Unique field(s): Unique field(s):
<itemizedlist Mark="bullet" Spacing="compact"> <itemizedlist>
<ListItem> <listitem>
<Para> <para>
Are used as an alternative access to the row. Are used as an alternative access to the row.
</Para> </para>
</ListItem> </listitem>
<ListItem> <listitem>
<Para> <para>
Are updateable, so long as they are kept unique. Are updateable, so long as they are kept unique.
</Para> </para>
</ListItem> </listitem>
<ListItem> <listitem>
<Para> <para>
NULLs are acceptable. NULLs are acceptable.
</Para> </para>
</ListItem> </listitem>
</itemizedlist> </itemizedlist>
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</para> </para>
<Para> <para>
As for why no non-unique keys are defined explicitly in standard <acronym>SQL</acronym> syntax? As for why no non-unique keys are defined explicitly in standard
Well, you <acronym>SQL</acronym> syntax?
must understand that indices are implementation-dependent. <acronym>SQL</acronym> does not Well, you
define the implementation, merely the relations between data in the must understand that indices are implementation-dependent. <acronym>SQL</acronym> does not
database. <productname>Postgres</productname> does allow non-unique indices, but indices define the implementation, merely the relations between data in the
used to enforce <acronym>SQL</acronym> keys are always unique. database. <productname>Postgres</productname> does allow non-unique indices, but indices
</Para> used to enforce <acronym>SQL</acronym> keys are always unique.
<Para> </para>
Thus, you may query a table by any combination of its columns, despite the <para>
fact that you don't have an index on these columns. The indexes are merely Thus, you may query a table by any combination of its columns, despite the
an implementational aid which each <acronym>RDBMS</acronym> offers you, in order to cause fact that you don't have an index on these columns. The indexes are merely
commonly used queries to be done more efficiently. Some <acronym>RDBMS</acronym> may give you an implementational aid which each <acronym>RDBMS</acronym> offers you, in order to cause
additional measures, such as keeping a key stored in main memory. They will commonly used queries to be done more efficiently. Some <acronym>RDBMS</acronym> may give you
have a special command, for example additional measures, such as keeping a key stored in main memory. They will
<programlisting> have a special command, for example
CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt; <programlisting>
</programlisting> CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt;
(this is not an existing command, just an example). </programlisting>
</Para> (this is not an existing command, just an example).
<Para> </para>
In fact, when you create a primary key or a unique combination of fields, <para>
nowhere in the <acronym>SQL</acronym> specification does it say that an index is created, nor that In fact, when you create a primary key or a unique combination of fields,
the retrieval of data by the key is going to be more efficient than a nowhere in the <acronym>SQL</acronym> specification does it say that an index is created, nor that
sequential scan! the retrieval of data by the key is going to be more efficient than a
</Para> sequential scan!
<Para> </para>
So, if you want to use a combination of fields which is not unique as a <para>
secondary key, you really don't have to specify anything - just start So, if you want to use a combination of fields which is not unique as a
retrieving by that combination! However, if you want to make the retrieval secondary key, you really don't have to specify anything - just start
efficient, you'll have to resort to the means your <acronym>RDBMS</acronym> provider gives you retrieving by that combination! However, if you want to make the retrieval
- be it an index, my imaginary MEMSTORE command, or an intelligent <acronym>RDBMS</acronym> efficient, you'll have to resort to the means your <acronym>RDBMS</acronym> provider gives you
which creates indices without your knowledge based on the fact that you have - be it an index, my imaginary MEMSTORE command, or an intelligent
sent it many queries based on a specific combination of keys... (It learns <acronym>RDBMS</acronym>
from experience). which creates indices without your knowledge based on the fact that you have
</Para> sent it many queries based on a specific combination of keys... (It learns
</chapter> from experience).
</para>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
--></book>
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v 1.2 2000/03/31 06:17:52 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v 1.3 2000/08/23 05:59:11 thomas Exp $
Postgres documentation Postgres documentation
--> -->
...@@ -135,11 +135,11 @@ ecpg [ -v ] [ -t ] [ -I include-path ] [ -o outfile ] file1 [ file2 ] [ ... ] ...@@ -135,11 +135,11 @@ ecpg [ -v ] [ -t ] [ -I include-path ] [ -o outfile ] file1 [ file2 ] [ ... ]
</para> </para>
<para> <para>
<ulink url="linus@epact.se">Linus Tolke</ulink> was the <ulink url="mailto:linus@epact.se">Linus Tolke</ulink> was the
original author of <application>ecpg</application> (up to version 0.2). original author of <application>ecpg</application> (up to version 0.2).
<ulink url="meskes@debian.org">Michael Meskes</ulink> <ulink url="mailto:meskes@debian.org">Michael Meskes</ulink>
is the current author and maintainer of <application>ecpg</application>. is the current author and maintainer of <application>ecpg</application>.
<ulink url="tomg@q8.nrnet.org">Thomas Good</ulink> <ulink url="mailto:tomg@q8.nrnet.org">Thomas Good</ulink>
is the author of the last revision of the ecpg man page, on which is the author of the last revision of the ecpg man page, on which
this document is based. this document is based.
</para> </para>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/insert.sgml,v 1.7 2000/03/27 17:14:43 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/ref/insert.sgml,v 1.8 2000/08/23 05:59:11 thomas Exp $
Postgres documentation Postgres documentation
--> -->
...@@ -20,20 +20,20 @@ Postgres documentation ...@@ -20,20 +20,20 @@ Postgres documentation
</refnamediv> </refnamediv>
<refsynopsisdiv> <refsynopsisdiv>
<refsynopsisdivinfo> <refsynopsisdivinfo>
<date>1999-07-20</date> <date>2000-08-08</date>
</refsynopsisdivinfo> </refsynopsisdivinfo>
<synopsis> <synopsis>
INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable class="PARAMETER">column</replaceable> [, ...] ) ] INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable class="PARAMETER">column</replaceable> [, ...] ) ]
{ VALUES ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) | SELECT <replaceable class="PARAMETER">query</replaceable> } { DEFAULT VALUES | VALUES ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) | SELECT <replaceable class="PARAMETER">query</replaceable> }
</synopsis> </synopsis>
<refsect2 id="R2-SQL-INSERT-1"> <refsect2 id="R2-SQL-INSERT-1">
<refsect2info> <refsect2info>
<date>1998-09-23</date>
</refsect2info> </refsect2info>
<title> <title>
Inputs Inputs
</title> </title>
<para> <para>
<variablelist> <variablelist>
...@@ -45,6 +45,7 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable ...@@ -45,6 +45,7 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><replaceable class="PARAMETER">column</replaceable></term> <term><replaceable class="PARAMETER">column</replaceable></term>
<listitem> <listitem>
...@@ -54,6 +55,16 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable ...@@ -54,6 +55,16 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry>
<term>DEFAULT VALUES</term>
<listitem>
<para>
All columns will be filled by NULLs or by values specified
when the table was created using DEFAULT clauses.
</para>
</listitem>
</varlistentry>
<varlistentry> <varlistentry>
<term><replaceable class="PARAMETER">expression</replaceable></term> <term><replaceable class="PARAMETER">expression</replaceable></term>
<listitem> <listitem>
...@@ -79,7 +90,6 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable ...@@ -79,7 +90,6 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable
<refsect2 id="R2-SQL-INSERT-2"> <refsect2 id="R2-SQL-INSERT-2">
<refsect2info> <refsect2info>
<date>1998-09-23</date>
</refsect2info> </refsect2info>
<title> <title>
Outputs Outputs
...@@ -118,7 +128,6 @@ INSERT 0 <replaceable>#</replaceable> ...@@ -118,7 +128,6 @@ INSERT 0 <replaceable>#</replaceable>
<refsect1 id="R1-SQL-INSERT-1"> <refsect1 id="R1-SQL-INSERT-1">
<refsect1info> <refsect1info>
<date>1998-09-02</date>
</refsect1info> </refsect1info>
<title> <title>
Description Description
...@@ -217,7 +226,6 @@ INSERT INTO tictactoe (game, board) ...@@ -217,7 +226,6 @@ INSERT INTO tictactoe (game, board)
<refsect2 id="R2-SQL-INSERT-4"> <refsect2 id="R2-SQL-INSERT-4">
<refsect2info> <refsect2info>
<date>1998-09-23</date>
</refsect2info> </refsect2info>
<title> <title>
SQL92 SQL92
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment