2266 lines
79 KiB
Plaintext
2266 lines
79 KiB
Plaintext
<appendix id="glossary">
|
|
<title>Glossary</title>
|
|
<para>
|
|
This is a list of terms and their meaning in the context of
|
|
<productname>PostgreSQL</productname> and relational database
|
|
systems in general.
|
|
</para>
|
|
|
|
<glosslist>
|
|
<glossentry id="glossary-acid">
|
|
<glossterm>ACID</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
<glossterm linkend="glossary-atomicity">Atomicity</glossterm>,
|
|
<glossterm linkend="glossary-consistency">Consistency</glossterm>,
|
|
<glossterm linkend="glossary-isolation">Isolation</glossterm>, and
|
|
<glossterm linkend="glossary-durability">Durability</glossterm>.
|
|
This set of properties of database transactions is intended to
|
|
guarantee validity in concurrent operation and even in event of
|
|
errors, power failures, etc.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-aggregate">
|
|
<glossterm>Aggregate function (routine)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-function">function</glossterm> that
|
|
combines (<firstterm>aggregates</firstterm>) multiple input values,
|
|
for example by counting, averaging or adding,
|
|
yielding a single output value.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="functions-aggregate"/>.
|
|
</para>
|
|
<glossseealso otherterm="glossary-window-function" />
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-am">
|
|
<glossterm>Access Method</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Interfaces which <productname>PostgreSQL</productname> use in order to
|
|
access data in tables and indexes. This abstraction allows for adding
|
|
support for new types of data storage.
|
|
</para>
|
|
<para>
|
|
For more information, see <xref linkend="tableam" /> and
|
|
<xref linkend="indexam" />.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Analytic function</glossterm>
|
|
<glosssee otherterm="glossary-window-function" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-analyze">
|
|
<glossterm>Analyze (operation)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The act of collecting statistics from data in
|
|
<glossterm linkend="glossary-table">tables</glossterm>
|
|
and other <glossterm linkend="glossary-relation">relations</glossterm>
|
|
to help the <glossterm linkend="glossary-planner">query planner</glossterm>
|
|
to make decisions about how to execute
|
|
<glossterm linkend="glossary-query">queries</glossterm>.
|
|
</para>
|
|
<para>
|
|
(Don't confuse this term with the <literal>ANALYZE</literal> option
|
|
to the <xref linkend="sql-explain"/> command.)
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-analyze"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-atomic">
|
|
<glossterm>Atomic</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
In reference to a <glossterm linkend="glossary-datum">datum</glossterm>:
|
|
the fact that its value cannot be broken down into smaller
|
|
components.
|
|
</para>
|
|
</glossdef>
|
|
<glossdef>
|
|
<para>
|
|
In reference to a
|
|
<glossterm linkend="glossary-transaction">database transaction</glossterm>:
|
|
see <glossterm linkend="glossary-atomicity">atomicity</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-atomicity">
|
|
<glossterm>Atomicity</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The property of a <glossterm linkend="glossary-transaction">transaction</glossterm>
|
|
that either all its operations complete as a single unit or none do.
|
|
In addition, if a system failure occurs during the execution of a
|
|
transaction, no partial results are visible after recovery.
|
|
This is one of the <acronym>ACID</acronym> properties.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-attribute">
|
|
<glossterm>Attribute</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An element with a certain name and data type found within a
|
|
<glossterm linkend="glossary-tuple">tuple</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-autovacuum">
|
|
<glossterm>Autovacuum (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A set of background processes that routinely perform
|
|
<glossterm linkend="glossary-vacuum">vacuum</glossterm>
|
|
and <glossterm linkend="glossary-analyze">analyze</glossterm> operations.
|
|
The <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
that coordinates the work and is always present (unless autovacuum
|
|
is disabled) is known as the <firstterm>autovacuum launcher</firstterm>,
|
|
and the processes that carry out the tasks are known as the
|
|
<firstterm>autovacuum workers</firstterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="autovacuum"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-auxiliary-proc">
|
|
<glossterm>Auxiliary process</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A process within an <glossterm linkend="glossary-instance">instance</glossterm>
|
|
that is in charge of some specific background task for the instance.
|
|
The auxiliary processes consist of <!-- in alphabetical order -->
|
|
<!-- NB: In the code, the autovac launcher doesn't use the auxiliary
|
|
process scaffolding; however it does behave as one so we list it
|
|
here anyway. In addition, logger isn't connected to shared memory so
|
|
most code outside postmaster.c doesn't even consider it a "proc" in
|
|
the first place.
|
|
-->
|
|
the <glossterm linkend="glossary-autovacuum">autovacuum launcher</glossterm>
|
|
(but not the autovacuum workers),
|
|
the <glossterm linkend="glossary-background-writer">background writer</glossterm>,
|
|
the <glossterm linkend="glossary-checkpointer">checkpointer</glossterm>,
|
|
the <glossterm linkend="glossary-logger">logger</glossterm>,
|
|
the <glossterm linkend="glossary-startup-process">startup process</glossterm>,
|
|
the <glossterm linkend="glossary-wal-archiver">WAL archiver</glossterm>,
|
|
the <glossterm linkend="glossary-wal-receiver">WAL receiver</glossterm>
|
|
(but not the <glossterm linkend="glossary-wal-sender">WAL senders</glossterm>),
|
|
and the <glossterm linkend="glossary-wal-writer">WAL writer</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-backend">
|
|
<glossterm>Backend (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Process of an <glossterm linkend="glossary-instance">instance</glossterm>
|
|
which acts on behalf of a <glossterm linkend="glossary-session">client session</glossterm>
|
|
and handles its requests.
|
|
</para>
|
|
<para>
|
|
(Don't confuse this term with the similar terms
|
|
<glossterm linkend="glossary-background-worker">Background Worker</glossterm> or
|
|
<glossterm linkend="glossary-background-writer">Background Writer</glossterm>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-background-worker">
|
|
<glossterm>Background worker (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Process within an <glossterm linkend="glossary-instance">instance</glossterm>,
|
|
which runs system- or user-supplied code.
|
|
Serves as infrastructure for several features in
|
|
<productname>PostgreSQL</productname>, such as
|
|
<glossterm linkend="glossary-replication">logical replication</glossterm>
|
|
and <glossterm linkend="glossary-parallel-query">parallel queries</glossterm>.
|
|
In addition, <glossterm linkend="glossary-extension">Extensions</glossterm> can add
|
|
custom background worker processes.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="bgworker"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-background-writer">
|
|
<glossterm>Background writer (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
that writes dirty
|
|
<glossterm linkend="glossary-data-page">data pages</glossterm> from
|
|
<glossterm linkend="glossary-shared-memory">shared memory</glossterm> to
|
|
the file system. It wakes up periodically, but works only for a short
|
|
period in order to distribute its expensive <acronym>I/O</acronym>
|
|
activity over time to avoid generating larger
|
|
<acronym>I/O</acronym> peaks which could block other processes.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="runtime-config-resource-background-writer"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-basebackup">
|
|
<glossterm>Base Backup</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A binary copy of all
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm>
|
|
files. It is generated by the tool <xref linkend="app-pgbasebackup"/>.
|
|
In combination with WAL files it can be used as the starting point
|
|
for recovery, log shipping, or streaming replication.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-bloat">
|
|
<glossterm>Bloat</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Space in data pages which does not contain current row versions,
|
|
such as unused (free) space or outdated row versions.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-bootstrap-superuser">
|
|
<glossterm>Bootstrap superuser</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The first <glossterm linkend="glossary-user">user</glossterm> initialized in a
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm>.
|
|
</para>
|
|
<para>
|
|
This user owns all system catalog tables in each database. It is also the role
|
|
from which all granted permissions originate. Because of these things, this
|
|
role may not be dropped.
|
|
</para>
|
|
<para>
|
|
This role also behaves as a normal
|
|
<glossterm linkend="glossary-database-superuser">database superuser</glossterm>,
|
|
and its superuser status cannot be removed.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-buffer-access-strategy">
|
|
<glossterm>Buffer Access Strategy</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Some operations will access a large number of
|
|
<glossterm linkend="glossary-data-page">pages</glossterm>. A
|
|
<firstterm>Buffer Access Strategy</firstterm> helps to prevent these
|
|
operations from evicting too many pages from
|
|
<glossterm linkend="glossary-shared-memory">shared buffers</glossterm>.
|
|
</para>
|
|
<para>
|
|
A Buffer Access Strategy sets up references to a limited number of
|
|
<glossterm linkend="glossary-shared-memory">shared buffers</glossterm> and
|
|
reuses them circularly. When the operation requires a new page, a victim
|
|
buffer is chosen from the buffers in the strategy ring, which may require
|
|
flushing the page's dirty data and possibly also unflushed
|
|
<glossterm linkend="glossary-wal">WAL</glossterm> to permanent storage.
|
|
</para>
|
|
<para>
|
|
Buffer Access Strategies are used for various operations such as
|
|
sequential scans of large tables, <command>VACUUM</command>,
|
|
<command>COPY</command>, <command>CREATE TABLE AS SELECT</command>,
|
|
<command>ALTER TABLE</command>, <command>CREATE DATABASE</command>,
|
|
<command>CREATE INDEX</command>, and <command>CLUSTER</command>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-cast">
|
|
<glossterm>Cast</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A conversion of a <glossterm linkend="glossary-datum">datum</glossterm>
|
|
from its current data type to another data type.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createcast"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-catalog">
|
|
<glossterm>Catalog</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The <acronym>SQL</acronym> standard uses this term to
|
|
indicate what is called a
|
|
<glossterm linkend="glossary-database">database</glossterm> in
|
|
<productname>PostgreSQL</productname>'s terminology.
|
|
</para>
|
|
<para>
|
|
(Don't confuse this term with
|
|
<glossterm linkend="glossary-system-catalog">system catalog</glossterm>).
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="manage-ag-overview"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-check-constraint">
|
|
<glossterm>Check constraint</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
|
|
defined on a <glossterm linkend="glossary-relation">relation</glossterm>
|
|
which restricts the values allowed in one or more
|
|
<glossterm linkend="glossary-attribute">attributes</glossterm>. The
|
|
check constraint can make reference to any attribute of the same row in
|
|
the relation, but cannot reference other rows of the same relation or
|
|
other relations.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="ddl-constraints"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-checkpoint">
|
|
<glossterm>Checkpoint</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A point in the <glossterm linkend="glossary-wal">WAL</glossterm> sequence
|
|
at which it is guaranteed that the heap and index data files have been
|
|
updated with all information from
|
|
<glossterm linkend="glossary-shared-memory">shared memory</glossterm>
|
|
modified before that checkpoint;
|
|
a <firstterm>checkpoint record</firstterm> is written and flushed to WAL
|
|
to mark that point.
|
|
</para>
|
|
<para>
|
|
A checkpoint is also the act of carrying out all the actions that
|
|
are necessary to reach a checkpoint as defined above.
|
|
This process is initiated when predefined conditions are met,
|
|
such as a specified amount of time has passed, or a certain volume
|
|
of records has been written; or it can be invoked by the user
|
|
with the command <command>CHECKPOINT</command>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="wal-configuration"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-checkpointer">
|
|
<glossterm>Checkpointer (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
that is responsible for executing
|
|
<glossterm linkend="glossary-checkpoint">checkpoints</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Class (archaic)</glossterm>
|
|
<glosssee otherterm="glossary-relation" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-client">
|
|
<glossterm>Client (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Any process, possibly remote, that establishes a
|
|
<glossterm linkend="glossary-session">session</glossterm>
|
|
by <glossterm linkend="glossary-connection">connecting</glossterm> to an
|
|
<glossterm linkend="glossary-instance">instance</glossterm>
|
|
to interact with a <glossterm linkend="glossary-database">database</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-cluster-owner">
|
|
<glossterm>Cluster owner</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The operating system user that owns the
|
|
<glossterm linkend="glossary-data-directory">data directory</glossterm>
|
|
and under which the <literal>postgres</literal> process is run.
|
|
It is required that this user exist prior to creating a new
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm>.
|
|
</para>
|
|
<para>
|
|
On operating systems with a <literal>root</literal> user,
|
|
said user is not allowed to be the cluster owner.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-column">
|
|
<glossterm>Column</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-attribute">attribute</glossterm> found in
|
|
a <glossterm linkend="glossary-table">table</glossterm> or
|
|
<glossterm linkend="glossary-view">view</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-commit">
|
|
<glossterm>Commit</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The act of finalizing a
|
|
<glossterm linkend="glossary-transaction">transaction</glossterm> within
|
|
the <glossterm linkend="glossary-database">database</glossterm>, which
|
|
makes it visible to other transactions and assures its
|
|
<glossterm linkend="glossary-durability">durability</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-commit"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-concurrency">
|
|
<glossterm>Concurrency</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The concept that multiple independent operations happen within the
|
|
<glossterm linkend="glossary-database">database</glossterm> at the same time.
|
|
In <productname>PostgreSQL</productname>, concurrency is controlled by
|
|
the <glossterm linkend="glossary-mvcc">multiversion concurrency control</glossterm>
|
|
mechanism.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-connection">
|
|
<glossterm>Connection</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An established line of communication between a client process and a
|
|
<glossterm linkend="glossary-backend">backend</glossterm> process,
|
|
usually over a network, supporting a
|
|
<glossterm linkend="glossary-session">session</glossterm>. This term is
|
|
sometimes used as a synonym for session.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="runtime-config-connection"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-consistency">
|
|
<glossterm>Consistency</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The property that the data in the
|
|
<glossterm linkend="glossary-database">database</glossterm>
|
|
is always in compliance with
|
|
<glossterm linkend="glossary-constraint">integrity constraints</glossterm>.
|
|
Transactions may be allowed to violate some of the constraints
|
|
transiently before it commits, but if such violations are not resolved
|
|
by the time it commits, such a transaction is automatically
|
|
<glossterm linkend="glossary-rollback">rolled back</glossterm>.
|
|
This is one of the <acronym>ACID</acronym> properties.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-constraint">
|
|
<glossterm>Constraint</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A restriction on the values of data allowed within a
|
|
<glossterm linkend="glossary-table">table</glossterm>,
|
|
or in attributes of a
|
|
<glossterm linkend="glossary-domain">domain</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="ddl-constraints"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-cumulative-statistics">
|
|
<glossterm>Cumulative Statistics System</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A system which, if enabled, accumulates statistical information
|
|
about the <glossterm linkend="glossary-instance">instance</glossterm>'s
|
|
activities.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="monitoring-stats"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Data area</glossterm>
|
|
<glosssee otherterm="glossary-data-directory" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-database">
|
|
<glossterm>Database</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A named collection of
|
|
<glossterm linkend="glossary-sql-object">local SQL objects</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="manage-ag-overview"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-db-cluster">
|
|
<glossterm>Database cluster</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A collection of databases and global SQL objects,
|
|
and their common static and dynamic metadata.
|
|
Sometimes referred to as a
|
|
<firstterm>cluster</firstterm>.
|
|
A database cluster is created using the
|
|
<xref linkend="app-initdb" /> program.
|
|
</para>
|
|
<para>
|
|
In <productname>PostgreSQL</productname>, the term
|
|
<firstterm>cluster</firstterm> is also sometimes used to refer to an instance.
|
|
(Don't confuse this term with the SQL command <command>CLUSTER</command>.)
|
|
</para>
|
|
<para>
|
|
See also <glossterm linkend="glossary-cluster-owner">cluster owner</glossterm>,
|
|
the operating-system owner of a cluster,
|
|
and <glossterm linkend="glossary-bootstrap-superuser">bootstrap superuser</glossterm>,
|
|
the <productname>PostgreSQL</productname> owner of a cluster.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Database server</glossterm>
|
|
<glosssee otherterm="glossary-instance" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-database-superuser">
|
|
<glossterm>Database superuser</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A role having <firstterm>superuser status</firstterm>
|
|
(see <xref linkend="role-attributes"/>).
|
|
</para>
|
|
<para>
|
|
Frequently referred to as <firstterm>superuser</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-data-directory">
|
|
<glossterm>Data directory</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The base directory on the file system of a
|
|
<glossterm linkend="glossary-server">server</glossterm> that contains all
|
|
data files and subdirectories associated with a
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm>
|
|
(with the exception of
|
|
<glossterm linkend="glossary-tablespace">tablespaces</glossterm>,
|
|
and optionally <glossterm linkend="glossary-wal">WAL</glossterm>).
|
|
The environment variable <literal>PGDATA</literal> is commonly used to
|
|
refer to the data directory.
|
|
</para>
|
|
<para>
|
|
A <glossterm linkend="glossary-db-cluster">cluster</glossterm>'s storage
|
|
space comprises the data directory plus any additional tablespaces.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="storage-file-layout"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-data-page">
|
|
<glossterm>Data page</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The basic structure used to store relation data.
|
|
All pages are of the same size.
|
|
Data pages are typically stored on disk, each in a specific file,
|
|
and can be read to <glossterm linkend="glossary-shared-memory">shared buffers</glossterm>
|
|
where they can be modified, becoming
|
|
<firstterm>dirty</firstterm>. They become clean when written
|
|
to disk. New pages, which initially exist in memory only, are also
|
|
dirty until written.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-datum">
|
|
<glossterm>Datum</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The internal representation of one value of an <acronym>SQL</acronym>
|
|
data type.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-delete">
|
|
<glossterm>Delete</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <acronym>SQL</acronym> command which removes
|
|
<glossterm linkend="glossary-tuple">rows</glossterm> from a given
|
|
<glossterm linkend="glossary-table">table</glossterm>
|
|
or <glossterm linkend="glossary-relation">relation</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-delete"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-domain">
|
|
<glossterm>Domain</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A user-defined data type that is based on another underlying data type.
|
|
It acts the same as the underlying type except for possibly restricting
|
|
the set of allowed values.
|
|
</para>
|
|
<para>
|
|
For more information, see <xref linkend="domains"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-durability">
|
|
<glossterm>Durability</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The assurance that once a
|
|
<glossterm linkend="glossary-transaction">transaction</glossterm> has
|
|
been <glossterm linkend="glossary-commit">committed</glossterm>, the
|
|
changes remain even after a system failure or crash.
|
|
This is one of the <acronym>ACID</acronym> properties.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Epoch</glossterm>
|
|
<glosssee otherterm="glossary-xid" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-extension">
|
|
<glossterm>Extension</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A software add-on package that can be installed on an
|
|
<glossterm linkend="glossary-instance">instance</glossterm> to
|
|
get extra features.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="extend-extensions" />.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-file-segment">
|
|
<glossterm>File segment</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A physical file which stores data for a given
|
|
<glossterm linkend="glossary-relation">relation</glossterm>.
|
|
File segments are limited in size by a configuration value
|
|
(typically 1 gigabyte),
|
|
so if a relation exceeds that size, it is split into multiple segments.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="storage-file-layout"/>.
|
|
</para>
|
|
<para>
|
|
(Don't confuse this term with the similar term
|
|
<glossterm linkend="glossary-wal-file">WAL segment</glossterm>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-foreign-data-wrapper">
|
|
<glossterm>Foreign data wrapper</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A means of representing data that is not contained in the local
|
|
<glossterm linkend="glossary-database">database</glossterm> so that it appears as if were in local
|
|
<glossterm linkend="glossary-table">table(s)</glossterm>. With a foreign data wrapper it is
|
|
possible to define a <glossterm linkend="glossary-foreign-server">foreign server</glossterm> and
|
|
<glossterm linkend="glossary-foreign-table">foreign tables</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createforeigndatawrapper"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-foreign-key">
|
|
<glossterm>Foreign key</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
|
|
defined on one or more <glossterm linkend="glossary-column">columns</glossterm>
|
|
in a <glossterm linkend="glossary-table">table</glossterm> which
|
|
requires the value(s) in those <glossterm linkend="glossary-column">columns</glossterm> to
|
|
identify zero or one <glossterm linkend="glossary-tuple">row</glossterm>
|
|
in another (or, infrequently, the same)
|
|
<glossterm linkend="glossary-table">table</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-foreign-server">
|
|
<glossterm>Foreign server</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A named collection of
|
|
<glossterm linkend="glossary-foreign-table">foreign tables</glossterm> which
|
|
all use the same
|
|
<glossterm linkend="glossary-foreign-data-wrapper">foreign data wrapper</glossterm>
|
|
and have other configuration values in common.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createserver"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-foreign-table">
|
|
<glossterm>Foreign table (relation)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-relation">relation</glossterm> which appears to have
|
|
<glossterm linkend="glossary-tuple">rows</glossterm> and
|
|
<glossterm linkend="glossary-column">columns</glossterm> similar to a
|
|
regular <glossterm linkend="glossary-table">table</glossterm>, but will forward
|
|
requests for data through its
|
|
<glossterm linkend="glossary-foreign-data-wrapper">foreign data wrapper</glossterm>,
|
|
which will return <glossterm linkend="glossary-result-set">result sets</glossterm>
|
|
structured according to the definition of the
|
|
<glossterm linkend="glossary-foreign-table">foreign table</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createforeigntable"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-fork">
|
|
<glossterm>Fork</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Each of the separate segmented file sets in which a relation is stored.
|
|
The <firstterm>main fork</firstterm> is where the actual data resides.
|
|
There also exist two secondary forks for metadata:
|
|
the <glossterm linkend="glossary-fsm">free space map</glossterm>
|
|
and the <glossterm linkend="glossary-vm">visibility map</glossterm>.
|
|
<glossterm linkend="glossary-unlogged">Unlogged relations</glossterm>
|
|
also have an <firstterm>init fork</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-fsm">
|
|
<glossterm>Free space map (fork)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A storage structure that keeps metadata about each data page of a table's
|
|
main fork. The free space map entry for each page stores the
|
|
amount of free space that's available for future tuples, and is structured
|
|
to be efficiently searched for available space for a new tuple of a given
|
|
size.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="storage-fsm"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-function">
|
|
<glossterm>Function (routine)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of routine that receives zero or more arguments, returns zero or more
|
|
output values, and is constrained to run within one transaction.
|
|
Functions are invoked as part of a query, for example via
|
|
<command>SELECT</command>.
|
|
Certain functions can return
|
|
<glossterm linkend="glossary-result-set">sets</glossterm>; those are
|
|
called <firstterm>set-returning functions</firstterm>.
|
|
</para>
|
|
<para>
|
|
Functions can also be used for
|
|
<glossterm linkend="glossary-trigger">triggers</glossterm> to invoke.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createfunction"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-grant">
|
|
<glossterm>Grant</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <acronym>SQL</acronym> command that is used to allow a
|
|
<glossterm linkend="glossary-user">user</glossterm> or
|
|
<glossterm linkend="glossary-role">role</glossterm> to access
|
|
specific objects within the <glossterm linkend="glossary-database">database</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-grant"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-heap">
|
|
<glossterm>Heap</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Contains the values of <glossterm linkend="glossary-tuple">row</glossterm>
|
|
attributes (i.e., the data) for a
|
|
<glossterm linkend="glossary-relation">relation</glossterm>.
|
|
The heap is realized within one or more
|
|
<glossterm linkend="glossary-file-segment">file segments</glossterm>
|
|
in the relation's <glossterm linkend="glossary-fork">main fork</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-host">
|
|
<glossterm>Host</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A computer that communicates with other computers over a network.
|
|
This is sometimes used as a synonym for
|
|
<glossterm linkend="glossary-server">server</glossterm>.
|
|
It is also used to refer to a computer where
|
|
<glossterm linkend="glossary-client">client processes</glossterm> run.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-index">
|
|
<glossterm>Index (relation)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-relation">relation</glossterm> that contains
|
|
data derived from a <glossterm linkend="glossary-table">table</glossterm>
|
|
or <glossterm linkend="glossary-materialized-view">materialized view</glossterm>.
|
|
Its internal structure supports fast retrieval of and access to the original
|
|
data.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createindex"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
<glossentry id="glossary-incremental-backup">
|
|
<glossterm>Incremental backup</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A special <glossterm linkend="glossary-basebackup">base backup</glossterm>
|
|
that for some files may contain only those pages that were modified since
|
|
a previous backup, as opposed to the full contents of every file. Like
|
|
base backups, it is generated by the tool <xref linkend="app-pgbasebackup"/>.
|
|
</para>
|
|
<para>
|
|
To restore incremental backups the tool <xref linkend="app-pgcombinebackup"/>
|
|
is used, which combines incremental backups with a base backup.
|
|
Afterwards, recovery can use
|
|
<glossterm linkend="glossary-wal">WAL</glossterm> to bring the
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm> to
|
|
a consistent state.
|
|
</para>
|
|
<para>
|
|
For more information, see <xref linkend="backup-incremental-backup"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-insert">
|
|
<glossterm>Insert</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <acronym>SQL</acronym> command used to add new data into a
|
|
<glossterm linkend="glossary-table">table</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-insert"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-instance">
|
|
<glossterm>Instance</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A group of <glossterm linkend="glossary-backend">backend</glossterm> and
|
|
<glossterm linkend="glossary-auxiliary-proc">auxiliary processes</glossterm>
|
|
that communicate using a common shared memory area. One
|
|
<glossterm linkend="glossary-postmaster">postmaster process</glossterm>
|
|
manages the instance; one instance manages exactly one
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm>
|
|
with all its databases. Many instances can run on the same
|
|
<glossterm linkend="glossary-server">server</glossterm>
|
|
as long as their <acronym>TCP</acronym> ports do not conflict.
|
|
</para>
|
|
<para>
|
|
The instance handles all key features of a <acronym>DBMS</acronym>:
|
|
read and write access to files and shared memory,
|
|
assurance of the <acronym>ACID</acronym> properties,
|
|
<glossterm linkend="glossary-connection">connections</glossterm> to
|
|
<glossterm linkend="glossary-client">client processes</glossterm>,
|
|
privilege verification, crash recovery, replication, etc.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-isolation">
|
|
<glossterm>Isolation</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The property that the effects of a transaction are not visible to
|
|
<glossterm linkend="glossary-concurrency">concurrent transactions</glossterm>
|
|
before it commits.
|
|
This is one of the <acronym>ACID</acronym> properties.
|
|
</para>
|
|
<para>
|
|
For more information, see <xref linkend="transaction-iso" />.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-join">
|
|
<glossterm>Join</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An operation and <acronym>SQL</acronym> keyword used in
|
|
<glossterm linkend="glossary-query">queries</glossterm>
|
|
for combining data from multiple
|
|
<glossterm linkend="glossary-relation">relations</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-key">
|
|
<glossterm>Key</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A means of identifying a <glossterm linkend="glossary-tuple">row</glossterm> within a
|
|
<glossterm linkend="glossary-table">table</glossterm> or
|
|
other <glossterm linkend="glossary-relation">relation</glossterm> by
|
|
values contained within one or more
|
|
<glossterm linkend="glossary-attribute">attributes</glossterm>
|
|
in that relation.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-lock">
|
|
<glossterm>Lock</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A mechanism that allows a process to limit or prevent simultaneous
|
|
access to a resource.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-log-file">
|
|
<glossterm>Log file</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Log files contain human-readable text lines about events.
|
|
Examples include login failures, long-running queries, etc.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="logfile-maintenance"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-logged">
|
|
<glossterm>Logged</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-table">table</glossterm> is considered
|
|
<glossterm linkend="glossary-logged">logged</glossterm> if changes to it are sent to the
|
|
<glossterm linkend="glossary-wal">WAL</glossterm>. By default, all regular
|
|
tables are logged. A table can be specified as
|
|
<glossterm linkend="glossary-unlogged">unlogged</glossterm> either at
|
|
creation time or via the <command>ALTER TABLE</command> command.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-logger">
|
|
<glossterm>Logger (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
which, if enabled, writes information about database events into the current
|
|
<glossterm linkend="glossary-log-file">log file</glossterm>.
|
|
When reaching certain time- or
|
|
volume-dependent criteria, a new log file is created.
|
|
Also called <firstterm>syslogger</firstterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="runtime-config-logging"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-log-record">
|
|
<glossterm>Log record</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Archaic term for a <glossterm linkend="glossary-wal-record">WAL record</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-log-sequence-number">
|
|
<glossterm>Log sequence number</glossterm>
|
|
<acronym>LSN</acronym>
|
|
<glossdef>
|
|
<para>
|
|
Byte offset into the <glossterm linkend="glossary-wal">WAL</glossterm>,
|
|
increasing monotonically with each new <glossterm
|
|
linkend="glossary-wal-record">WAL record</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see <link
|
|
linkend="datatype-pg-lsn"><type>pg_lsn</type></link> and <xref
|
|
linkend="wal-internals"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>LSN</glossterm>
|
|
<glosssee otherterm="glossary-log-sequence-number"/>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Master (server)</glossterm>
|
|
<glosssee otherterm="glossary-primary-server" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-materialized">
|
|
<glossterm>Materialized</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The property that some information has been pre-computed and stored
|
|
for later use, rather than computing it on-the-fly.
|
|
</para>
|
|
<para>
|
|
This term is used in
|
|
<glossterm linkend="glossary-materialized-view">materialized view</glossterm>,
|
|
to mean that the data derived from the view's query is stored on
|
|
disk separately from the sources of that data.
|
|
</para>
|
|
<para>
|
|
This term is also used to refer to some multi-step queries to mean that
|
|
the data resulting from executing a given step is stored in memory
|
|
(with the possibility of spilling to disk), so that it can be read multiple
|
|
times by another step.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-materialized-view">
|
|
<glossterm>Materialized view (relation)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-relation">relation</glossterm> that is
|
|
defined by a <command>SELECT</command> statement
|
|
(just like a <glossterm linkend="glossary-view">view</glossterm>),
|
|
but stores data in the same way that a
|
|
<glossterm linkend="glossary-table">table</glossterm> does. It cannot be
|
|
modified via <command>INSERT</command>, <command>UPDATE</command>,
|
|
<command>DELETE</command>, or <command>MERGE</command> operations.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-creatematerializedview"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-merge">
|
|
<glossterm>Merge</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <acronym>SQL</acronym> command used to conditionally add, modify,
|
|
or remove <glossterm linkend="glossary-tuple">rows</glossterm>
|
|
in a given <glossterm linkend="glossary-table">table</glossterm>,
|
|
using data from a source
|
|
<glossterm linkend="glossary-relation">relation</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-merge"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-mvcc">
|
|
<glossterm>Multi-version concurrency control (MVCC)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A mechanism designed to allow several
|
|
<glossterm linkend="glossary-transaction">transactions</glossterm> to be
|
|
reading and writing the same rows without one process causing other
|
|
processes to stall.
|
|
In <productname>PostgreSQL</productname>, MVCC is implemented by
|
|
creating copies (<firstterm>versions</firstterm>) of
|
|
<glossterm linkend="glossary-tuple">tuples</glossterm> as they are
|
|
modified; after transactions that can see the old versions terminate,
|
|
those old versions need to be removed.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-null">
|
|
<glossterm>Null</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A concept of non-existence that is a central tenet of relational
|
|
database theory. It represents the absence of a definite value.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Optimizer</glossterm>
|
|
<glosssee otherterm="glossary-planner" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-parallel-query">
|
|
<glossterm>Parallel query</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The ability to handle parts of executing a
|
|
<glossterm linkend="glossary-query">query</glossterm> to take advantage
|
|
of parallel processes on servers with multiple <acronym>CPU</acronym>s.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-partition">
|
|
<glossterm>Partition</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
One of several disjoint (not overlapping) subsets of a larger set.
|
|
</para>
|
|
</glossdef>
|
|
<glossdef>
|
|
<para>
|
|
In reference to a
|
|
<glossterm linkend="glossary-partitioned-table">partitioned table</glossterm>:
|
|
One of the tables that each contain part of the data of the partitioned table,
|
|
which is said to be the <firstterm>parent</firstterm>.
|
|
The partition is itself a table, so it can also be queried directly;
|
|
at the same time, a partition can sometimes be a partitioned table,
|
|
allowing hierarchies to be created.
|
|
</para>
|
|
</glossdef>
|
|
<glossdef>
|
|
<para>
|
|
In reference to a <glossterm linkend="glossary-window-function">window function</glossterm>
|
|
in a <glossterm linkend="glossary-query">query</glossterm>,
|
|
a partition is a user-defined criterion that identifies which neighboring
|
|
<glossterm linkend="glossary-tuple">rows</glossterm>
|
|
of the <glossterm linkend="glossary-result-set">query's result set</glossterm>
|
|
can be considered by the function.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-partitioned-table">
|
|
<glossterm>Partitioned table (relation)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-relation">relation</glossterm> that is
|
|
in semantic terms the same as a <glossterm linkend="glossary-table">table</glossterm>,
|
|
but whose storage is distributed across several
|
|
<glossterm linkend="glossary-partition">partitions</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-postmaster">
|
|
<glossterm>Postmaster (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The very first process of an <glossterm linkend="glossary-instance">instance</glossterm>.
|
|
It starts and manages the
|
|
<glossterm linkend="glossary-auxiliary-proc">auxiliary processes</glossterm>
|
|
and creates <glossterm linkend="glossary-backend">backend processes</glossterm>
|
|
on demand.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="server-start"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-primary-key">
|
|
<glossterm>Primary key</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A special case of a
|
|
<glossterm linkend="glossary-unique-constraint">unique constraint</glossterm>
|
|
defined on a
|
|
<glossterm linkend="glossary-table">table</glossterm> or other
|
|
<glossterm linkend="glossary-relation">relation</glossterm> that also
|
|
guarantees that all of the
|
|
<glossterm linkend="glossary-attribute">attributes</glossterm>
|
|
within the <glossterm linkend="glossary-primary-key">primary key</glossterm>
|
|
do not have <glossterm linkend="glossary-null">null</glossterm> values.
|
|
As the name implies, there can be only one
|
|
primary key per table, though it is possible to have multiple unique
|
|
constraints that also have no null-capable attributes.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-primary-server">
|
|
<glossterm>Primary (server)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
When two or more <glossterm linkend="glossary-database">databases</glossterm>
|
|
are linked via <glossterm linkend="glossary-replication">replication</glossterm>,
|
|
the <glossterm linkend="glossary-server">server</glossterm>
|
|
that is considered the authoritative source of information is called
|
|
the <firstterm>primary</firstterm>,
|
|
also known as a <firstterm>master</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-procedure">
|
|
<glossterm>Procedure (routine)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of routine.
|
|
Their distinctive qualities are that they do not return values,
|
|
and that they are allowed to make transactional statements such
|
|
as <command>COMMIT</command> and <command>ROLLBACK</command>.
|
|
They are invoked via the <command>CALL</command> command.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createprocedure"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-query">
|
|
<glossterm>Query</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A request sent by a client to a <glossterm linkend="glossary-backend">backend</glossterm>,
|
|
usually to return results or to modify data on the database.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-planner">
|
|
<glossterm>Query planner</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The part of <productname>PostgreSQL</productname> that is devoted to
|
|
determining (<firstterm>planning</firstterm>) the most efficient way to
|
|
execute <glossterm linkend="glossary-query">queries</glossterm>.
|
|
Also known as <firstterm>query optimizer</firstterm>,
|
|
<firstterm>optimizer</firstterm>, or simply <firstterm>planner</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Record</glossterm>
|
|
<glosssee otherterm="glossary-tuple" />
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Recycling</glossterm>
|
|
<glosssee otherterm="glossary-wal-file" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-referential-integrity">
|
|
<glossterm>Referential integrity</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A means of restricting data in one <glossterm linkend="glossary-relation">relation</glossterm>
|
|
by a <glossterm linkend="glossary-foreign-key">foreign key</glossterm>
|
|
so that it must have matching data in another
|
|
<glossterm linkend="glossary-relation">relation</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-relation">
|
|
<glossterm>Relation</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The generic term for all objects in a
|
|
<glossterm linkend="glossary-database">database</glossterm>
|
|
that have a name and a list of
|
|
<glossterm linkend="glossary-attribute">attributes</glossterm>
|
|
defined in a specific order.
|
|
<glossterm linkend="glossary-table">Tables</glossterm>,
|
|
<glossterm linkend="glossary-sequence">sequences</glossterm>,
|
|
<glossterm linkend="glossary-view">views</glossterm>,
|
|
<glossterm linkend="glossary-foreign-table">foreign tables</glossterm>,
|
|
<glossterm linkend="glossary-materialized-view">materialized views</glossterm>,
|
|
composite types, and
|
|
<glossterm linkend="glossary-index">indexes</glossterm> are all relations.
|
|
</para>
|
|
<para>
|
|
More generically, a relation is a set of tuples; for example,
|
|
the result of a query is also a relation.
|
|
</para>
|
|
<para>
|
|
In <productname>PostgreSQL</productname>,
|
|
<firstterm>Class</firstterm> is an archaic synonym for
|
|
<firstterm>relation</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-replica">
|
|
<glossterm>Replica (server)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-database">database</glossterm> that is paired
|
|
with a <glossterm linkend="glossary-primary-server">primary</glossterm>
|
|
database and is maintaining a copy of some or all of the primary database's
|
|
data. The foremost reasons for doing this are to allow for greater access
|
|
to that data, and to maintain availability of the data in the event that
|
|
the <glossterm linkend="glossary-primary-server">primary</glossterm>
|
|
becomes unavailable.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-replication">
|
|
<glossterm>Replication</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The act of reproducing data on one
|
|
<glossterm linkend="glossary-server">server</glossterm> onto another
|
|
server called a <glossterm linkend="glossary-replica">replica</glossterm>.
|
|
This can take the form of <firstterm>physical replication</firstterm>,
|
|
where all file changes from one server are copied verbatim,
|
|
or <firstterm>logical replication</firstterm> where a defined subset
|
|
of data changes are conveyed using a higher-level representation.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-restartpoint">
|
|
<glossterm>Restartpoint</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A variant of a <glossterm
|
|
linkend="glossary-checkpoint">checkpoint</glossterm> performed on a
|
|
<glossterm linkend="glossary-replica">replica</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see <xref linkend="wal-configuration"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-result-set">
|
|
<glossterm>Result set</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-relation">relation</glossterm> transmitted
|
|
from a <glossterm linkend="glossary-backend">backend process</glossterm>
|
|
to a <glossterm linkend="glossary-client">client</glossterm> upon the
|
|
completion of an <acronym>SQL</acronym> command, usually a
|
|
<command>SELECT</command> but it can be an
|
|
<command>INSERT</command>, <command>UPDATE</command>,
|
|
<command>DELETE</command>, or <command>MERGE</command> command if the
|
|
<literal>RETURNING</literal> clause is specified.
|
|
</para>
|
|
<para>
|
|
The fact that a result set is a relation means that a query can be used
|
|
in the definition of another query, becoming a
|
|
<firstterm>subquery</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
<glossdef>
|
|
<para>
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-revoke">
|
|
<glossterm>Revoke</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A command to prevent access to a named set of
|
|
<glossterm linkend="glossary-database">database</glossterm> objects for a
|
|
named list of <glossterm linkend="glossary-role">roles</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-revoke"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-role">
|
|
<glossterm>Role</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A collection of access privileges to the
|
|
<glossterm linkend="glossary-database">instance</glossterm>.
|
|
Roles are themselves a privilege that can be granted to other roles.
|
|
This is often done for convenience or to ensure completeness
|
|
when multiple <glossterm linkend="glossary-user">users</glossterm> need
|
|
the same privileges.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createrole"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-rollback">
|
|
<glossterm>Rollback</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A command to undo all of the operations performed since the beginning
|
|
of a <glossterm linkend="glossary-transaction">transaction</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-rollback"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-routine">
|
|
<glossterm>Routine</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A defined set of instructions stored in the database system
|
|
that can be invoked for execution.
|
|
A routine can be written in a variety of programming
|
|
languages. Routines can be
|
|
<glossterm linkend="glossary-function">functions</glossterm>
|
|
(including set-returning functions and
|
|
<glossterm linkend="glossary-trigger">trigger functions</glossterm>),
|
|
<glossterm linkend="glossary-aggregate">aggregate functions</glossterm>,
|
|
and <glossterm linkend="glossary-procedure">procedures</glossterm>.
|
|
</para>
|
|
<para>
|
|
Many routines are already defined within <productname>PostgreSQL</productname>
|
|
itself, but user-defined ones can also be added.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Row</glossterm>
|
|
<glosssee otherterm="glossary-tuple" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-savepoint">
|
|
<glossterm>Savepoint</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A special mark in the sequence of steps in a
|
|
<glossterm linkend="glossary-transaction">transaction</glossterm>.
|
|
Data modifications after this point in time may be reverted
|
|
to the time of the savepoint.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-savepoint"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-schema">
|
|
<glossterm>Schema</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A schema is a namespace for
|
|
<glossterm linkend="glossary-sql-object">SQL objects</glossterm>,
|
|
which all reside in the same
|
|
<glossterm linkend="glossary-database">database</glossterm>.
|
|
Each SQL object must reside in exactly one schema.
|
|
</para>
|
|
<para>
|
|
All system-defined SQL objects reside in schema <literal>pg_catalog</literal>.
|
|
</para>
|
|
</glossdef>
|
|
<glossdef>
|
|
<para>
|
|
More generically, the term <firstterm>schema</firstterm> is used to mean
|
|
all data descriptions (<glossterm linkend="glossary-table">table</glossterm> definitions,
|
|
<glossterm linkend="glossary-constraint">constraints</glossterm>, comments, etc.)
|
|
for a given <glossterm linkend="glossary-database">database</glossterm> or
|
|
subset thereof.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="ddl-schemas"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Segment</glossterm>
|
|
<glosssee otherterm="glossary-file-segment" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-select">
|
|
<glossterm>Select</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The <acronym>SQL</acronym> command used to request data from a
|
|
<glossterm linkend="glossary-database">database</glossterm>.
|
|
Normally, <command>SELECT</command> commands are not expected to modify the
|
|
<glossterm linkend="glossary-database">database</glossterm> in any way,
|
|
but it is possible that
|
|
<glossterm linkend="glossary-function">functions</glossterm> invoked within
|
|
the query could have side effects that do modify data.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-select"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-sequence">
|
|
<glossterm>Sequence (relation)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of relation that is used to generate values.
|
|
Typically the generated values are sequential non-repeating numbers.
|
|
They are commonly used to generate surrogate
|
|
<glossterm linkend="glossary-primary-key">primary key</glossterm>
|
|
values.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<!-- XXX should define all other isolation levels (and improve this definition)
|
|
<glossentry id="glossary-serializable">
|
|
<glossterm>Serializable (isolation level)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Transactions defined as <literal>SERIALIZABLE</literal> are unable to
|
|
see changes made within other transactions. In effect, for the
|
|
initializing session the entire <glossterm linkend="glossary-database">database</glossterm>
|
|
appears to be frozen for the duration of the
|
|
<glossterm linkend="glossary-transaction">Transaction</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
-->
|
|
|
|
<glossentry id="glossary-server">
|
|
<glossterm>Server</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A computer on which <productname>PostgreSQL</productname>
|
|
<glossterm linkend="glossary-instance">instances</glossterm> run.
|
|
The term <firstterm>server</firstterm> denotes real hardware, a
|
|
container, or a <firstterm>virtual machine</firstterm>.
|
|
</para>
|
|
<para>
|
|
This term is sometimes used to refer to an instance or to a host.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-session">
|
|
<glossterm>Session</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A state that allows a client and a backend to interact,
|
|
communicating over a <glossterm linkend="glossary-connection">connection</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-shared-memory">
|
|
<glossterm>Shared memory</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
<acronym>RAM</acronym> which is used by the processes common to an
|
|
<glossterm linkend="glossary-instance">instance</glossterm>.
|
|
It mirrors parts of <glossterm linkend="glossary-database">database</glossterm>
|
|
files, provides a transient area for
|
|
<glossterm linkend="glossary-wal-record">WAL records</glossterm>,
|
|
and stores additional common information.
|
|
Note that shared memory belongs to the complete instance, not to a single
|
|
database.
|
|
</para>
|
|
<para>
|
|
The largest part of shared memory is known as <firstterm>shared buffers</firstterm>
|
|
and is used to mirror part of data files, organized into pages.
|
|
When a page is modified, it is called a dirty page until it is
|
|
written back to the file system.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="runtime-config-resource-memory"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-sql-object">
|
|
<glossterm>SQL object</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Any object that can be created with a <command>CREATE</command>
|
|
command. Most objects are specific to one database, and are commonly
|
|
known as <firstterm>local objects</firstterm>.
|
|
</para>
|
|
<para>
|
|
Most local objects reside in a specific
|
|
<glossterm linkend="glossary-schema">schema</glossterm> in their
|
|
containing database, such as
|
|
<glossterm linkend="glossary-relation">relations</glossterm> (all types),
|
|
<glossterm linkend="glossary-function">routines</glossterm> (all types),
|
|
data types, etc.
|
|
The names of such objects of the same type in the same schema
|
|
are enforced to be unique.
|
|
</para>
|
|
<para>
|
|
There also exist local objects that do not reside in schemas; some examples are
|
|
<glossterm linkend="glossary-extension">extensions</glossterm>,
|
|
<glossterm linkend="glossary-cast">data type casts</glossterm>, and
|
|
<glossterm linkend="glossary-foreign-data-wrapper">foreign data wrappers</glossterm>.
|
|
The names of such objects of the same type are enforced to be unique
|
|
within the database.
|
|
</para>
|
|
<para>
|
|
Other object types, such as
|
|
<glossterm linkend="glossary-role">roles</glossterm>,
|
|
<glossterm linkend="glossary-tablespace">tablespaces</glossterm>,
|
|
replication origins, subscriptions for logical replication, and
|
|
databases themselves are not local SQL objects since they exist
|
|
entirely outside of any specific database;
|
|
they are called <firstterm>global objects</firstterm>.
|
|
The names of such objects are enforced to be unique within the whole
|
|
database cluster.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="manage-ag-overview"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-sql-standard">
|
|
<glossterm>SQL standard</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A series of documents that define the <acronym>SQL</acronym> language.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>Standby (server)</glossterm>
|
|
<glosssee otherterm="glossary-replica" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-startup-process">
|
|
<glossterm>Startup process</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
that replays WAL during crash recovery and in a
|
|
<glossterm linkend="glossary-replication">physical replica</glossterm>.
|
|
</para>
|
|
<para>
|
|
(The name is historical: the startup process was named before
|
|
replication was implemented; the name refers to its task as it
|
|
relates to the server startup following a crash.)
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-superuser">
|
|
<glossterm>Superuser</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
As used in this documentation, it is a synonym for
|
|
<glossterm linkend="glossary-database-superuser">database superuser</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-system-catalog">
|
|
<glossterm>System catalog</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A collection of <glossterm linkend="glossary-table">tables</glossterm>
|
|
which describe the structure of all
|
|
<glossterm linkend="glossary-sql-object">SQL objects</glossterm>
|
|
of the instance.
|
|
The system catalog resides in the schema <literal>pg_catalog</literal>.
|
|
These tables contain data in internal representation and are
|
|
not typically considered useful for user examination;
|
|
a number of user-friendlier <glossterm linkend="glossary-view">views</glossterm>,
|
|
also in schema <literal>pg_catalog</literal>, offer more convenient access to
|
|
some of that information, while additional tables and views
|
|
exist in schema <literal>information_schema</literal>
|
|
(see <xref linkend="information-schema" />) that expose some
|
|
of the same and additional information as mandated by the
|
|
<glossterm linkend="glossary-sql-standard">SQL standard</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="ddl-schemas"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-table">
|
|
<glossterm>Table</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A collection of <glossterm linkend="glossary-tuple">tuples</glossterm> having
|
|
a common data structure (the same number of
|
|
<glossterm linkend="glossary-attribute">attributes</glossterm>, in the same
|
|
order, having the same name and type per position).
|
|
A table is the most common form of
|
|
<glossterm linkend="glossary-relation">relation</glossterm> in
|
|
<productname>PostgreSQL</productname>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createtable"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-tablespace">
|
|
<glossterm>Tablespace</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A named location on the server file system.
|
|
All <glossterm linkend="glossary-sql-object">SQL objects</glossterm>
|
|
which require storage beyond their definition in the
|
|
<glossterm linkend="glossary-system-catalog">system catalog</glossterm>
|
|
must belong to a single tablespace.
|
|
Initially, a database cluster contains a single usable tablespace which is
|
|
used as the default for all SQL objects, called <literal>pg_default</literal>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="manage-ag-tablespaces"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-temporary-table">
|
|
<glossterm>Temporary table</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
<glossterm linkend="glossary-table">Tables</glossterm> that exist either
|
|
for the lifetime of a
|
|
<glossterm linkend="glossary-session">session</glossterm> or a
|
|
<glossterm linkend="glossary-transaction">transaction</glossterm>, as
|
|
specified at the time of creation.
|
|
The data in them is not visible to other sessions, and is not
|
|
<glossterm linkend="glossary-logged">logged</glossterm>.
|
|
Temporary tables are often used to store intermediate data for a
|
|
multi-step operation.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createtable"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-toast">
|
|
<glossterm>TOAST</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A mechanism by which large attributes of table rows are split and
|
|
stored in a secondary table, called the <firstterm>TOAST table</firstterm>.
|
|
Each relation with large attributes has its own TOAST table.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="storage-toast" />.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-transaction">
|
|
<glossterm>Transaction</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A combination of commands that must act as a single
|
|
<glossterm linkend="glossary-atomic">atomic</glossterm> command: they all
|
|
succeed or all fail as a single unit, and their effects are not visible to
|
|
other <glossterm linkend="glossary-session">sessions</glossterm> until
|
|
the transaction is complete, and possibly even later, depending on the
|
|
isolation level.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="transaction-iso"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-xid">
|
|
<glossterm>Transaction ID</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The numerical, unique, sequentially-assigned identifier that each
|
|
transaction receives when it first causes a database modification.
|
|
Frequently abbreviated as <firstterm>xid</firstterm>.
|
|
When stored on disk, xids are only 32-bits wide, so only
|
|
approximately four billion write transaction IDs can be generated;
|
|
to permit the system to run for longer than that,
|
|
<firstterm>epochs</firstterm> are used, also 32 bits wide.
|
|
When the counter reaches the maximum xid value, it starts over at
|
|
<literal>3</literal> (values under that are reserved) and the
|
|
epoch value is incremented by one.
|
|
In some contexts, the epoch and xid values are
|
|
considered together as a single 64-bit value; see <xref
|
|
linkend="transaction-id"/> for more details.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="datatype-oid"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-tps">
|
|
<glossterm>Transactions per second (TPS)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Average number of transactions that are executed per second,
|
|
totaled across all sessions active for a measured run.
|
|
This is used as a measure of the performance characteristics of
|
|
an instance.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-trigger">
|
|
<glossterm>Trigger</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-function">function</glossterm> which can
|
|
be defined to execute whenever a certain operation (<command>INSERT</command>,
|
|
<command>UPDATE</command>, <command>DELETE</command>,
|
|
<command>TRUNCATE</command>) is applied to a
|
|
<glossterm linkend="glossary-relation">relation</glossterm>.
|
|
A trigger executes within the same
|
|
<glossterm linkend="glossary-transaction">transaction</glossterm> as the
|
|
statement which invoked it, and if the function fails, then the invoking
|
|
statement also fails.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createtrigger"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-tuple">
|
|
<glossterm>Tuple</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A collection of <glossterm linkend="glossary-attribute">attributes</glossterm>
|
|
in a fixed order.
|
|
That order may be defined by the <glossterm linkend="glossary-table">table</glossterm>
|
|
(or other <glossterm linkend="glossary-relation">relation</glossterm>)
|
|
where the tuple is contained, in which case the tuple is often called a
|
|
<firstterm>row</firstterm>. It may also be defined by the structure of a
|
|
result set, in which case it is sometimes called a <firstterm>record</firstterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-unique-constraint">
|
|
<glossterm>Unique constraint</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
|
|
defined on a <glossterm linkend="glossary-relation">relation</glossterm>
|
|
which restricts the values allowed in one or a combination of columns
|
|
so that each value or combination of values can only appear once in the
|
|
relation — that is, no other row in the relation contains values
|
|
that are equal to those.
|
|
</para>
|
|
<para>
|
|
Because <glossterm linkend="glossary-null">null values</glossterm> are
|
|
not considered equal to each other, multiple rows with null values are
|
|
allowed to exist without violating the unique constraint.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-unlogged">
|
|
<glossterm>Unlogged</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The property of certain <glossterm linkend="glossary-relation">relations</glossterm>
|
|
that the changes to them are not reflected in the
|
|
<glossterm linkend="glossary-wal">WAL</glossterm>.
|
|
This disables replication and crash recovery for these relations.
|
|
</para>
|
|
<para>
|
|
The primary use of unlogged tables is for storing
|
|
transient work data that must be shared across processes.
|
|
</para>
|
|
<para>
|
|
<glossterm linkend="glossary-temporary-table">Temporary tables</glossterm>
|
|
are always unlogged.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-update">
|
|
<glossterm>Update</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <acronym>SQL</acronym> command used to modify
|
|
<glossterm linkend="glossary-tuple">rows</glossterm>
|
|
that may already exist in a specified <glossterm linkend="glossary-table">table</glossterm>.
|
|
It cannot create or remove rows.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-update"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-user">
|
|
<glossterm>User</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-role">role</glossterm> that has the
|
|
<firstterm>login privilege</firstterm>
|
|
(see <xref linkend="role-attributes"/>).
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-user-mapping">
|
|
<glossterm>User mapping</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The translation of login credentials in the local
|
|
<glossterm linkend="glossary-database">database</glossterm> to credentials
|
|
in a remote data system defined by a
|
|
<glossterm linkend="glossary-foreign-data-wrapper">foreign data wrapper</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createusermapping"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-vacuum">
|
|
<glossterm>Vacuum</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The process of removing outdated
|
|
<glossterm linkend="glossary-tuple">tuple versions</glossterm>
|
|
from tables or materialized views, and other closely related
|
|
processing required by <productname>PostgreSQL</productname>'s
|
|
implementation of <glossterm linkend="glossary-mvcc">MVCC</glossterm>.
|
|
This can be initiated through the use of
|
|
the <command>VACUUM</command> command, but can also be handled automatically
|
|
via <glossterm linkend="glossary-autovacuum">autovacuum</glossterm> processes.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="routine-vacuuming"/> .
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-view">
|
|
<glossterm>View</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A <glossterm linkend="glossary-relation">relation</glossterm> that is defined by a
|
|
<command>SELECT</command> statement, but has no storage of its own.
|
|
Any time a query references a view, the definition of the view is
|
|
substituted into the query as if the user had typed it as a subquery
|
|
instead of the name of the view.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="sql-createview"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-vm">
|
|
<glossterm>Visibility map (fork)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A storage structure that keeps metadata about each data page
|
|
of a table's main fork. The visibility map entry for
|
|
each page stores two bits: the first one
|
|
(<literal>all-visible</literal>) indicates that all tuples
|
|
in the page are visible to all transactions. The second one
|
|
(<literal>all-frozen</literal>) indicates that all tuples
|
|
in the page are marked frozen.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>WAL</glossterm>
|
|
<glosssee otherterm="glossary-wal" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-archiver">
|
|
<glossterm>WAL archiver (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
which, if enabled, saves copies of
|
|
<glossterm linkend="glossary-wal-file">WAL files</glossterm>
|
|
for the purpose of creating backups or keeping
|
|
<glossterm linkend="glossary-replica">replicas</glossterm> current.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="continuous-archiving"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-file">
|
|
<glossterm>WAL file</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
Also known as <firstterm>WAL segment</firstterm> or
|
|
<firstterm>WAL segment file</firstterm>.
|
|
Each of the sequentially-numbered files that provide storage space for
|
|
<glossterm linkend="glossary-wal">WAL</glossterm>.
|
|
The files are all of the same predefined size
|
|
and are written in sequential order, interspersing changes
|
|
as they occur in multiple simultaneous sessions.
|
|
If the system crashes, the files are read in order, and each of the
|
|
changes is replayed to restore the system to the state it was in
|
|
before the crash.
|
|
</para>
|
|
<para>
|
|
Each WAL file can be released after a
|
|
<glossterm linkend="glossary-checkpoint">checkpoint</glossterm>
|
|
writes all the changes in it to the corresponding data files.
|
|
Releasing the file can be done either by deleting it, or by changing its
|
|
name so that it will be used in the future, which is called
|
|
<firstterm>recycling</firstterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="wal-internals"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-record">
|
|
<glossterm>WAL record</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A low-level description of an individual data change.
|
|
It contains sufficient information for the data change to be
|
|
re-executed (<firstterm>replayed</firstterm>) in case a system failure
|
|
causes the change to be lost.
|
|
WAL records use a non-printable binary format.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="wal-internals"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-receiver">
|
|
<glossterm>WAL receiver (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
|
|
that runs on a <glossterm linkend="glossary-replica">replica</glossterm>
|
|
to receive WAL from the
|
|
<glossterm linkend="glossary-primary-server">primary server</glossterm>
|
|
for replay by the
|
|
<glossterm linkend="glossary-startup-process">startup process</glossterm>.
|
|
</para>
|
|
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="warm-standby"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry>
|
|
<glossterm>WAL segment</glossterm>
|
|
<glosssee otherterm="glossary-wal-file" />
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-sender">
|
|
<glossterm>WAL sender (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A special <glossterm linkend="glossary-backend">backend process</glossterm>
|
|
that streams WAL over a network. The receiving end can be a
|
|
<glossterm linkend="glossary-wal-receiver">WAL receiver</glossterm>
|
|
in a <glossterm linkend="glossary-replica">replica</glossterm>,
|
|
<xref linkend="app-pgreceivewal"/>, or any other client program
|
|
that speaks the replication protocol.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-summarizer">
|
|
<glossterm>WAL summarizer (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A special <glossterm linkend="glossary-backend">backend process</glossterm>
|
|
that summarizes WAL data for
|
|
<glossterm linkend="glossary-incremental-backup">incremental backups</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see <xref linkend="runtime-config-wal-summarization"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal-writer">
|
|
<glossterm>WAL writer (process)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A process that writes <glossterm linkend="glossary-wal-record">WAL records</glossterm>
|
|
from <glossterm linkend="glossary-shared-memory">shared memory</glossterm> to
|
|
<glossterm linkend="glossary-wal-file">WAL files</glossterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="runtime-config-wal"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-window-function">
|
|
<glossterm>Window function (routine)</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
A type of <glossterm linkend="glossary-function">function</glossterm>
|
|
used in a <glossterm linkend="glossary-query">query</glossterm>
|
|
that applies to a <glossterm linkend="glossary-partition">partition</glossterm>
|
|
of the query's <glossterm linkend="glossary-result-set">result set</glossterm>;
|
|
the function's result is based on values found in
|
|
<glossterm linkend="glossary-tuple">rows</glossterm> of the same partition or frame.
|
|
</para>
|
|
<para>
|
|
All <glossterm linkend="glossary-aggregate">aggregate functions</glossterm>
|
|
can be used as window functions, but window functions can also be
|
|
used to, for example, give ranks to each of the rows in the partition.
|
|
Also known as <firstterm>analytic functions</firstterm>.
|
|
</para>
|
|
<para>
|
|
For more information, see
|
|
<xref linkend="tutorial-window"/>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
|
|
<glossentry id="glossary-wal">
|
|
<glossterm>Write-ahead log</glossterm>
|
|
<glossdef>
|
|
<para>
|
|
The journal that keeps track of the changes in the
|
|
<glossterm linkend="glossary-db-cluster">database cluster</glossterm>
|
|
as user- and system-invoked operations take place.
|
|
It comprises many individual
|
|
<glossterm linkend="glossary-wal-record">WAL records</glossterm> written
|
|
sequentially to <glossterm linkend="glossary-wal-file">WAL files</glossterm>.
|
|
</para>
|
|
</glossdef>
|
|
</glossentry>
|
|
</glosslist>
|
|
</appendix>
|