postgresql/doc/src/sgml/postgres.sgml

283 lines
7.7 KiB
Plaintext
Raw Normal View History

2010-09-20 22:08:53 +02:00
<!-- doc/src/sgml/postgres.sgml -->
2003-11-24 20:08:02 +01:00
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [
<!ENTITY % version SYSTEM "version.sgml">
%version;
<!ENTITY % filelist SYSTEM "filelist.sgml">
%filelist;
<!ENTITY reference SYSTEM "reference.sgml">
1998-03-01 09:16:16 +01:00
]>
<book id="postgres">
<title>PostgreSQL &version; Documentation</title>
<bookinfo>
<corpauthor>The PostgreSQL Global Development Group</corpauthor>
<productname>PostgreSQL</productname>
<productnumber>&version;</productnumber>
&legal;
</bookinfo>
&intro;
<part id="tutorial">
<title>Tutorial</title>
<partintro>
<para>
Welcome to the <productname>PostgreSQL</productname> Tutorial. The
following few chapters are intended to give a simple introduction
to <productname>PostgreSQL</productname>, relational database
concepts, and the SQL language to those who are new to any one of
these aspects. We only assume some general knowledge about how to
use computers. No particular Unix or programming experience is
required. This part is mainly intended to give you some hands-on
experience with important aspects of the
<productname>PostgreSQL</productname> system. It makes no attempt
to be a complete or thorough treatment of the topics it covers.
</para>
<para>
After you have worked through this tutorial you might want to move
on to reading <xref linkend="sql"> to gain a more formal knowledge
of the SQL language, or <xref linkend="client-interfaces"> for
information about developing applications for
<productname>PostgreSQL</productname>. Those who set up and
manage their own server should also read <xref linkend="admin">.
</para>
</partintro>
&start;
&query;
&advanced;
</part>
<part id="sql">
<title>The SQL Language</title>
<partintro>
<para>
This part describes the use of the <acronym>SQL</acronym> language
in <productname>PostgreSQL</productname>. We start with
describing the general syntax of <acronym>SQL</acronym>, then
explain how to create the structures to hold data, how to populate
the database, and how to query it. The middle part lists the
available data types and functions for use in
<acronym>SQL</acronym> commands. The rest treats several
aspects that are important for tuning a database for optimal
performance.
</para>
<para>
The information in this part is arranged so that a novice user can
follow it start to end to gain a full understanding of the topics
without having to refer forward too many times. The chapters are
intended to be self-contained, so that advanced users can read the
chapters individually as they choose. The information in this
part is presented in a narrative fashion in topical units.
Readers looking for a complete description of a particular command
should see <xref linkend="reference">.
</para>
<para>
2003-11-04 10:55:39 +01:00
Readers of this part should know how to connect to a
<productname>PostgreSQL</> database and issue
<acronym>SQL</acronym> commands. Readers that are unfamiliar with
these issues are encouraged to read <xref linkend="tutorial">
first. <acronym>SQL</acronym> commands are typically entered
using the <productname>PostgreSQL</> interactive terminal
<application>psql</application>, but other programs that have
similar functionality can be used as well.
</para>
</partintro>
&syntax;
&ddl;
&dml;
&queries;
&datatype;
&func;
&typeconv;
&indices;
&textsearch;
&mvcc;
&perform;
&parallel;
</part>
<part id="admin">
<title>Server Administration</title>
<partintro>
<para>
This part covers topics that are of interest to a
<productname>PostgreSQL</> database administrator. This includes
installation of the software, set up and configuration of the
server, management of users and databases, and maintenance tasks.
2004-12-24 20:12:37 +01:00
Anyone who runs a <productname>PostgreSQL</> server, even for
personal use, but especially in production, should be familiar
with the topics covered in this part.
</para>
<para>
The information in this part is arranged approximately in the
order in which a new user should read it. But the chapters are
self-contained and can be read individually as desired. The
information in this part is presented in a narrative fashion in
topical units. Readers looking for a complete description of a
particular command should see <xref linkend="reference">.
</para>
<para>
The first few chapters are written so they can be understood
without prerequisite knowledge, so new users who need to set
up their own server can begin their exploration with this part.
The rest of this part is about tuning and management; that material
2004-12-24 20:12:37 +01:00
assumes that the reader is familiar with the general use of
the <productname>PostgreSQL</> database system. Readers are
encouraged to look at <xref linkend="tutorial"> and <xref
linkend="sql"> for additional information.
</para>
</partintro>
&installation;
&installw;
&runtime;
&config;
&client-auth;
&user-manag;
&manage-ag;
&charset;
&maintenance;
&backup;
&high-availability;
&recovery-config;
&monitoring;
&diskusage;
&wal;
&regress;
</part>
<part id="client-interfaces">
<title>Client Interfaces</title>
<partintro>
<para>
This part describes the client programming interfaces distributed
with <productname>PostgreSQL</>. Each of these chapters can be
read independently. Note that there are many other programming
interfaces for client programs that are distributed separately and
contain their own documentation (<xref linkend="external-projects">
lists some of the more popular ones). Readers of this part should be
familiar with using <acronym>SQL</acronym> commands to manipulate
and query the database (see <xref linkend="sql">) and of course
with the programming language that the interface uses.
</para>
</partintro>
&libpq;
&lobj;
&ecpg;
&infoschema;
</part>
<part id="server-programming">
<title>Server Programming</title>
<partintro>
<para>
This part is about extending the server functionality with
user-defined functions, data types, triggers, etc. These are
advanced topics which should probably be approached only after all
the other user documentation about <productname>PostgreSQL</> has
been understood. Later chapters in this part describe the server-side
programming languages available in the
<productname>PostgreSQL</productname> distribution as well as
general issues concerning server-side programming languages. It
is essential to read at least the earlier sections of <xref
linkend="extend"> (covering functions) before diving into the
material about server-side programming languages.
</para>
</partintro>
&extend;
&trigger;
&event-trigger;
&rules;
&xplang;
&plsql;
&pltcl;
&plperl;
&plpython;
&spi;
Background worker processes Background workers are postmaster subprocesses that run arbitrary user-specified code. They can request shared memory access as well as backend database connections; or they can just use plain libpq frontend database connections. Modules listed in shared_preload_libraries can register background workers in their _PG_init() function; this is early enough that it's not necessary to provide an extra GUC option, because the necessary extra resources can be allocated early on. Modules can install more than one bgworker, if necessary. Care is taken that these extra processes do not interfere with other postmaster tasks: only one such process is started on each ServerLoop iteration. This means a large number of them could be waiting to be started up and postmaster is still able to quickly service external connection requests. Also, shutdown sequence should not be impacted by a worker process that's reasonably well behaved (i.e. promptly responds to termination signals.) The current implementation lets worker processes specify their start time, i.e. at what point in the server startup process they are to be started: right after postmaster start (in which case they mustn't ask for shared memory access), when consistent state has been reached (useful during recovery in a HOT standby server), or when recovery has terminated (i.e. when normal backends are allowed). In case of a bgworker crash, actions to take depend on registration data: if shared memory was requested, then all other connections are taken down (as well as other bgworkers), just like it were a regular backend crashing. The bgworker itself is restarted, too, within a configurable timeframe (which can be configured to be never). More features to add to this framework can be imagined without much effort, and have been discussed, but this seems good enough as a useful unit already. An elementary sample module is supplied. Author: Álvaro Herrera This patch is loosely based on prior patches submitted by KaiGai Kohei, and unsubmitted code by Simon Riggs. Reviewed by: KaiGai Kohei, Markus Wanner, Andres Freund, Heikki Linnakangas, Simon Riggs, Amit Kapila
2012-12-06 18:57:52 +01:00
&bgworker;
&logicaldecoding;
Introduce replication progress tracking infrastructure. When implementing a replication solution ontop of logical decoding, two related problems exist: * How to safely keep track of replication progress * How to change replication behavior, based on the origin of a row; e.g. to avoid loops in bi-directional replication setups The solution to these problems, as implemented here, consist out of three parts: 1) 'replication origins', which identify nodes in a replication setup. 2) 'replication progress tracking', which remembers, for each replication origin, how far replay has progressed in a efficient and crash safe manner. 3) The ability to filter out changes performed on the behest of a replication origin during logical decoding; this allows complex replication topologies. E.g. by filtering all replayed changes out. Most of this could also be implemented in "userspace", e.g. by inserting additional rows contain origin information, but that ends up being much less efficient and more complicated. We don't want to require various replication solutions to reimplement logic for this independently. The infrastructure is intended to be generic enough to be reusable. This infrastructure also replaces the 'nodeid' infrastructure of commit timestamps. It is intended to provide all the former capabilities, except that there's only 2^16 different origins; but now they integrate with logical decoding. Additionally more functionality is accessible via SQL. Since the commit timestamp infrastructure has also been introduced in 9.5 (commit 73c986add) changing the API is not a problem. For now the number of origins for which the replication progress can be tracked simultaneously is determined by the max_replication_slots GUC. That GUC is not a perfect match to configure this, but there doesn't seem to be sufficient reason to introduce a separate new one. Bumps both catversion and wal page magic. Author: Andres Freund, with contributions from Petr Jelinek and Craig Ringer Reviewed-By: Heikki Linnakangas, Petr Jelinek, Robert Haas, Steve Singer Discussion: 20150216002155.GI15326@awork2.anarazel.de, 20140923182422.GA15776@alap3.anarazel.de, 20131114172632.GE7522@alap2.anarazel.de
2015-04-29 19:30:53 +02:00
&replication-origins;
</part>
&reference;
<part id="internals">
<title>Internals</title>
<partintro>
<para>
This part contains assorted information that might be of use to
<productname>PostgreSQL</> developers.
</para>
</partintro>
&arch-dev;
&catalogs;
&protocol;
&sources;
&nls;
&plhandler;
&fdwhandler;
Redesign tablesample method API, and do extensive code review. The original implementation of TABLESAMPLE modeled the tablesample method API on index access methods, which wasn't a good choice because, without specialized DDL commands, there's no way to build an extension that can implement a TSM. (Raw inserts into system catalogs are not an acceptable thing to do, because we can't undo them during DROP EXTENSION, nor will pg_upgrade behave sanely.) Instead adopt an API more like procedural language handlers or foreign data wrappers, wherein the only SQL-level support object needed is a single handler function identified by having a special return type. This lets us get rid of the supporting catalog altogether, so that no custom DDL support is needed for the feature. Adjust the API so that it can support non-constant tablesample arguments (the original coding assumed we could evaluate the argument expressions at ExecInitSampleScan time, which is undesirable even if it weren't outright unsafe), and discourage sampling methods from looking at invisible tuples. Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable within and across queries, as required by the SQL standard, and deal more honestly with methods that can't support that requirement. Make a full code-review pass over the tablesample additions, and fix assorted bugs, omissions, infelicities, and cosmetic issues (such as failure to put the added code stanzas in a consistent ordering). Improve EXPLAIN's output of tablesample plans, too. Back-patch to 9.5 so that we don't have to support the original API in production.
2015-07-25 20:39:00 +02:00
&tablesample-method;
&custom-scan;
&geqo;
&indexam;
&generic-wal;
&gist;
&spgist;
2006-09-14 15:40:28 +02:00
&gin;
BRIN: Block Range Indexes BRIN is a new index access method intended to accelerate scans of very large tables, without the maintenance overhead of btrees or other traditional indexes. They work by maintaining "summary" data about block ranges. Bitmap index scans work by reading each summary tuple and comparing them with the query quals; all pages in the range are returned in a lossy TID bitmap if the quals are consistent with the values in the summary tuple, otherwise not. Normal index scans are not supported because these indexes do not store TIDs. As new tuples are added into the index, the summary information is updated (if the block range in which the tuple is added is already summarized) or not; in the latter case, a subsequent pass of VACUUM or the brin_summarize_new_values() function will create the summary information. For data types with natural 1-D sort orders, the summary info consists of the maximum and the minimum values of each indexed column within each page range. This type of operator class we call "Minmax", and we supply a bunch of them for most data types with B-tree opclasses. Since the BRIN code is generalized, other approaches are possible for things such as arrays, geometric types, ranges, etc; even for things such as enum types we could do something different than minmax with better results. In this commit I only include minmax. Catalog version bumped due to new builtin catalog entries. There's more that could be done here, but this is a good step forwards. Loosely based on ideas from Simon Riggs; code mostly by Álvaro Herrera, with contribution by Heikki Linnakangas. Patch reviewed by: Amit Kapila, Heikki Linnakangas, Robert Haas. Testing help from Jeff Janes, Erik Rijkers, Emanuel Calvo. PS: The research leading to these results has received funding from the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 318633.
2014-11-07 20:38:14 +01:00
&brin;
&storage;
&bki;
&planstats;
</part>
<part id="appendixes">
<title>Appendixes</title>
&errcodes;
&datetime;
&keywords;
&features;
&release;
&contrib;
&external-projects;
&sourcerepo;
&docguide;
&acronyms;
</part>
&biblio;
<![%include-index;[&bookindex;]]>
<![%include-xslt-index;[<index id="bookindex"></index>]]>
</book>