Re: Add A Glossary
Thanks everybody. I have compiled together all the suggestions and the
result is in the attached patch. Some of it is of my own devising.
* I changed "instance", and made "cluster" be mostly a synonym of that.
* I removed "global SQL object" and made "SQL object" explain it.
* Added definitions for ACID, sequence, bloat, fork, FSM, VM, data page,
transaction ID, epoch.
* Changed "a SQL" to "an sql" everywhere.
* Sorted alphabetically.
* Removed caps in term names.
I think I should get this pushed, and if there are further suggestions,
they're welcome.
Dim Fontaine and others suggested a number of terms that could be
included; see https://twitter.com/alvherre/status/1246192786287865856
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
glossfixes-2.patchtext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/acronyms.sgml b/doc/src/sgml/acronyms.sgml
index f638665dc9..b05c065546 100644
--- a/doc/src/sgml/acronyms.sgml
+++ b/doc/src/sgml/acronyms.sgml
@@ -766,7 +766,7 @@
<term><acronym>XID</acronym></term>
<listitem>
<para>
- <link linkend="datatype-oid">Transaction Identifier</link>
+ <glossterm linkend="glossary-xid">Transaction identifier</glossterm>
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 8c6cb6e942..d4255215aa 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -7,8 +7,22 @@
</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>.
+ A set of properties of database transactions 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</glossterm>
+ <glossterm>Aggregate function</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-function">function</glossterm> that
@@ -35,11 +49,15 @@
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>
</glossdef>
</glossentry>
<glossentry>
- <glossterm>Analytic Function</glossterm>
+ <glossterm>Analytic function</glossterm>
<glosssee otherterm="glossary-window-function" />
</glossentry>
@@ -106,8 +124,8 @@
<glossdef>
<para>
Process of an <glossterm linkend="glossary-instance">instance</glossterm>
- which act on behalf of <glossterm linkend="glossary-session">client sessions</glossterm>
- and handle their requests.
+ 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
@@ -118,7 +136,7 @@
</glossentry>
<glossentry id="glossary-background-worker">
- <glossterm>Background Worker (process)</glossterm>
+ <glossterm>Background worker (process)</glossterm>
<glossdef>
<para>
Process within an <glossterm linkend="glossary-instance">instance</glossterm>,
@@ -138,10 +156,11 @@
</glossentry>
<glossentry id="glossary-background-writer">
- <glossterm>Background Writer (process)</glossterm>
+ <glossterm>Background writer (process)</glossterm>
<glossdef>
<para>
- A process that continuously writes dirty pages from
+ A process that continuously 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>
@@ -155,6 +174,16 @@
</glossdef>
</glossentry>
+ <glossentry id="glossary-bloat">
+ <glossterm>Bloat</glossterm>
+ <glossdef>
+ <para>
+ Space in data pages which does not contain relevant data,
+ such as unused (free) space or outdated row versions.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id="glossary-cast">
<glossterm>Cast</glossterm>
<glossdef>
@@ -190,7 +219,7 @@
</glossentry>
<glossentry id="glossary-check-constraint">
- <glossterm>Check Constraint</glossterm>
+ <glossterm>Check constraint</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
@@ -208,15 +237,6 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-checkpointer">
- <glossterm>Checkpointer (process)</glossterm>
- <glossdef>
- <para>
- A specialized process responsible for executing checkpoints.
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id="glossary-checkpoint">
<glossterm>Checkpoint</glossterm>
<glossdef>
@@ -244,6 +264,15 @@
</glossdef>
</glossentry>
+ <glossentry id="glossary-checkpointer">
+ <glossterm>Checkpointer (process)</glossterm>
+ <glossdef>
+ <para>
+ A specialized process responsible for executing checkpoints.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry>
<glossterm>Class (archaic)</glossterm>
<glosssee otherterm="glossary-relation" />
@@ -262,27 +291,6 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-cluster">
- <glossterm>Cluster</glossterm>
- <glossdef>
- <para>
- A group of <glossterm linkend="glossary-database">databases</glossterm> plus their
- <glossterm linkend="glossary-global-sql-object">global SQL objects</glossterm>. The
- <firstterm>cluster</firstterm> is managed by exactly one
- <glossterm linkend="glossary-instance">instance</glossterm>. A newly created
- Cluster will have three databases created automatically. They are
- <literal>template0</literal>, <literal>template1</literal>, and
- <literal>postgres</literal>. It is expected that an application will
- create one or more additional database aside from these three.
- </para>
- <para>
- (Don't confuse the <productname>PostgreSQL</productname>-specific term
- <glossterm linkend="glossary-cluster">Cluster</glossterm> with the SQL
- command <command>CLUSTER</command>).
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id="glossary-column">
<glossterm>Column</glossterm>
<glossdef>
@@ -363,7 +371,10 @@
<glossdef>
<para>
A restriction on the values of data allowed within a
- <glossterm linkend="glossary-table">Table</glossterm>.
+ <glossterm linkend="glossary-table">table</glossterm>,
+ or in attributes of a
+ <!-- XXX Should have term "domain". Need term "type" for that. -->
+ <firstterm>domain</firstterm>.
</para>
<para>
For more information, see
@@ -373,18 +384,18 @@
</glossentry>
<glossentry>
- <glossterm>Data Area</glossterm>
+ <glossterm>Data area</glossterm>
<glosssee otherterm="glossary-data-directory" />
</glossentry>
<glossentry id="glossary-data-directory">
- <glossterm>Data Directory</glossterm>
+ <glossterm>Data directory</glossterm>
<glossdef>
<para>
The base directory on the filesystem of a
<glossterm linkend="glossary-server">server</glossterm> that contains all
data files and subdirectories associated with a
- <glossterm linkend="glossary-cluster">cluster</glossterm> with the
+ <glossterm linkend="glossary-instance">instance</glossterm> with the
exception of <glossterm linkend="glossary-tablespace">tablespaces</glossterm>.
The environment variable <literal>PGDATA</literal> is commonly used to
refer to the
@@ -416,15 +427,31 @@
</glossentry>
<glossentry>
- <glossterm>Database Server</glossterm>
+ <glossterm>Database server</glossterm>
<glosssee otherterm="glossary-instance" />
</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 get clean by being written down
+ 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 a <acronym>SQL</acronym>
+ The internal representation of one value of an <acronym>SQL</acronym>
data type.
</para>
</glossdef>
@@ -434,7 +461,7 @@
<glossterm>Delete</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command which removes
+ 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>.
@@ -459,6 +486,11 @@
</glossdef>
</glossentry>
+ <glossentry>
+ <glossterm>Epoch</glossterm>
+ <glosssee otherterm="glossary-xid" />
+ </glossentry>
+
<glossentry id="glossary-extension">
<glossterm>Extension</glossterm>
<glossdef>
@@ -475,12 +507,13 @@
</glossentry>
<glossentry id="glossary-file-segment">
- <glossterm>File Segment</glossterm>
+ <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,
+ 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>
@@ -495,14 +528,14 @@
</glossentry>
<glossentry id="glossary-foreign-data-wrapper">
- <glossterm>Foreign Data Wrapper</glossterm>
+ <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
+ <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 table</glossterm>s.
+ <glossterm linkend="glossary-foreign-table">foreign tables</glossterm>.
</para>
<para>
For more information, see
@@ -512,7 +545,7 @@
</glossentry>
<glossentry id="glossary-foreign-key">
- <glossterm>Foreign Key</glossterm>
+ <glossterm>Foreign key</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
@@ -527,7 +560,7 @@
</glossentry>
<glossentry id="glossary-foreign-server">
- <glossterm>Foreign Server</glossterm>
+ <glossterm>Foreign server</glossterm>
<glossdef>
<para>
A named collection of
@@ -544,7 +577,7 @@
</glossentry>
<glossentry id="glossary-foreign-table">
- <glossterm>Foreign Table</glossterm>
+ <glossterm>Foreign table</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> which appears to have
@@ -564,6 +597,35 @@
</glossdef>
</glossentry>
+ <glossentry id="glossary-fork">
+ <glossterm>Fork</glossterm>
+ <glossdef>
+ <para>
+ Each of the separate segmented file sets that a relation stores its
+ data in. There exist a <firstterm>main fork</firstterm> and two secondary
+ forks: the <glossterm linkend="glossary-fsm">free space map</glossterm>
+ <glossterm linkend="glossary-vm">visibility map</glossterm>.
+ </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 in a table's
+ main storage space. The free space map entry for each space stores the
+ amount of free space that's available for future tuples, and is structured
+ so it is efficient to search 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</glossterm>
<glossdef>
@@ -579,28 +641,11 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-global-sql-object">
- <glossterm>Global SQL Object</glossterm>
- <glossdef>
- <para>
- <glossterm linkend="glossary-sql-object">SQL objects</glossterm> which do
- not belong to a specific
- <glossterm linkend="glossary-database">database</glossterm>.
- </para>
- <para>
- These objects are
- <glossterm linkend="glossary-role">roles</glossterm>,
- <glossterm linkend="glossary-tablespace">tablespaces</glossterm>,
- replication origins, and subscriptions for logical replication.
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id="glossary-grant">
<glossterm>Grant</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command that is used to allow
+ An <acronym>SQL</acronym> command that is used to allow
<glossterm linkend="glossary-user">users</glossterm> or
<glossterm linkend="glossary-role">role</glossterm> to access
specific objects within the <glossterm linkend="glossary-database">database</glossterm>.
@@ -620,7 +665,8 @@
attributes (i.e. the data) for a
<glossterm linkend="glossary-relation">relation</glossterm>.
The heap is realized within
- <glossterm linkend="glossary-file-segment">segment files</glossterm>.
+ <glossterm linkend="glossary-file-segment">segmented files</glossterm>
+ in the relation's <glossterm linkend="glossary-fork">main fork</glossterm>.
</para>
</glossdef>
</glossentry>
@@ -629,10 +675,11 @@
<glossterm>Host</glossterm>
<glossdef>
<para>
- A computer that communicates with other hosts over a network.
- This term can be used to refer to either a
- <glossterm linkend="glossary-client">client</glossterm>
- or a <glossterm linkend="glossary-server">server</glossterm>.
+ 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>
@@ -659,7 +706,7 @@
<glossterm>Insert</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command used to add new data into a
+ An <acronym>SQL</acronym> command used to add new data into a
<glossterm linkend="glossary-table">table</glossterm>.
</para>
<para>
@@ -673,27 +720,28 @@
<glossterm>Instance</glossterm>
<glossdef>
<para>
- An <glossterm>instance</glossterm> is a group of processes,
- its supporting <glossterm linkend="glossary-data-directory">storage space</glossterm>,
- plus their
- common <glossterm linkend="glossary-shared-memory">shared memory</glossterm>,
- running on a single <glossterm linkend="glossary-server">server</glossterm>.
- The <glossterm linkend="glossary-instance">instance</glossterm>
- handles all key features of a <acronym>DBMS</acronym>: read and write
- access to files and shared memory, assurance of
- the <acronym>ACID</acronym> paradigm, <acronym>MVCC</acronym>,
- <glossterm linkend="glossary-connection">connections</glossterm> to client programs, backup,
- recovery, replication, privileges, etc.
+ A set of databases and accompanying global SQL objects that are stored in
+ the same <glossterm linkend="glossary-data-directory">data directory</glossterm>
+ in a single <glossterm linkend="glossary-server">server</glossterm>.
+ If running, one
+ <glossterm linkend="glossary-postmaster">postmaster process</glossterm>
+ manages a group of backend and auxiliary processes that communicate
+ using a common <glossterm linkend="glossary-shared-memory">shared memory</glossterm>
+ area. 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>
- An <glossterm>instance</glossterm> manages exactly one
- <glossterm linkend="glossary-cluster">cluster</glossterm>.
+ 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 client processes,
+ backup, recovery, replication, privileges, etc.
</para>
<para>
- Many <glossterm>instances</glossterm> can run on the same server as
- long as their <acronym>TCP/IP</acronym> ports do not conflict.
- Different instances on a server may use the
- same or different versions of <productname>PostgreSQL</productname>.
+ 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>
</glossdef>
</glossentry>
@@ -717,7 +765,7 @@
<glossterm>Join</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> keyword used in <command>SELECT</command> statements for
+ An <acronym>SQL</acronym> keyword used in <command>SELECT</command> statements for
combining data from multiple <glossterm linkend="glossary-relation">relations</glossterm>.
</para>
</glossdef>
@@ -748,7 +796,7 @@
</glossentry>
<glossentry id="glossary-log-file">
- <glossterm>Log File</glossterm>
+ <glossterm>Log file</glossterm>
<glossdef>
<para>
Log files contain human-readable text lines about events.
@@ -761,6 +809,29 @@
</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-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>
@@ -780,29 +851,6 @@
</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-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>
<glossterm>Master (server)</glossterm>
<glosssee otherterm="glossary-primary-server" />
@@ -831,7 +879,7 @@
</glossentry>
<glossentry id="glossary-materialized-view">
- <glossterm>Materialized View</glossterm>
+ <glossterm>Materialized view</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
@@ -869,8 +917,8 @@
<glossterm>Null</glossterm>
<glossdef>
<para>
- A concept of non-existence that is a central tenet of Relational
- Database Theory. It represents the absence of value.
+ 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>
@@ -881,7 +929,7 @@
</glossentry>
<glossentry id="glossary-parallel-query">
- <glossterm>Parallel Query</glossterm>
+ <glossterm>Parallel query</glossterm>
<glossdef>
<para>
The ability to handle parts of executing a
@@ -918,7 +966,7 @@
</glossentry>
<glossentry id="glossary-partitioned-table">
- <glossterm>Partitioned Table</glossterm>
+ <glossterm>Partitioned table</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
@@ -960,7 +1008,7 @@
</glossentry>
<glossentry id="glossary-primary-key">
- <glossterm>Primary Key</glossterm>
+ <glossterm>Primary key</glossterm>
<glossdef>
<para>
A special case of a
@@ -1011,7 +1059,7 @@
</glossentry>
<glossentry id="glossary-planner">
- <glossterm>Query Planner</glossterm>
+ <glossterm>Query planner</glossterm>
<glossdef>
<para>
The part of <productname>PostgreSQL</productname> that is devoted to
@@ -1034,7 +1082,7 @@
</glossentry>
<glossentry id="glossary-referential-integrity">
- <glossterm>Referential Integrity</glossterm>
+ <glossterm>Referential integrity</glossterm>
<glossdef>
<para>
A means of restricting data in one <glossterm linkend="glossary-relation">relation</glossterm>
@@ -1055,6 +1103,7 @@
<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>, and
@@ -1068,7 +1117,7 @@
</glossentry>
<glossentry id="glossary-replica">
- <glossterm>Replica</glossterm>
+ <glossterm>Replica (server)</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-database">database</glossterm> that is paired
@@ -1098,12 +1147,13 @@
</glossentry>
<glossentry id="glossary-result-set">
- <glossterm>Result Set</glossterm>
+ <glossterm>Result set</glossterm>
<glossdef>
<para>
A data structure transmitted from a
<glossterm linkend="glossary-backend">backend process</glossterm> to
- client program upon the completion of a <acronym>SQL</acronym>
+ 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>, or
<command>DELETE</command> command if the <literal>RETURNING</literal>
@@ -1135,7 +1185,7 @@
<para>
A collection of access privileges to the
<glossterm linkend="glossary-database">instance</glossterm>.
- Roless are themselves a privilege that can be granted to other roles.
+ 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.
@@ -1170,7 +1220,7 @@
<glossterm>Savepoint</glossterm>
<glossdef>
<para>
- A special mark inside the sequence of steps in a
+ 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.
@@ -1186,13 +1236,15 @@
<glossterm>Schema</glossterm>
<glossdef>
<para>
- A schema is a namespace for <glossterm linkend="glossary-sql-object">SQL objects</glossterm>,
+ 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>
- The names of SQL objects of the same type in the same schema are enforced unique.
+ The names of SQL objects of the same type in the same schema are enforced
+ to be unique.
There is no restriction on reusing a name in multiple schemas.
</para>
<para>
@@ -1205,7 +1257,7 @@
</glossdef>
<glossdef>
<para>
- More generically, the term <firstterm>Schema</firstterm> is used to mean
+ 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
@@ -1264,7 +1316,10 @@
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 Virtual Machine.
+ 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>
@@ -1279,45 +1334,21 @@
</glossdef>
</glossentry>
-<!-- XXX we should have a much more concise definition
<glossentry id="glossary-sequence">
<glossterm>Sequence</glossterm>
<glossdef>
<para>
- A <glossterm linkend="glossary-database">Database</glossterm> object which
- represents the mathematical concept of a numerical integral sequence.
- It can be thought of as a <glossterm linkend="glossary-table">Table</glossterm>
- with exactly one <glossterm linkend="glossary-tuple">Row</glossterm> and
- one <glossterm linkend="glossary-column">Column</glossterm>. The
- value stored is known as the current value. A
- <glossterm linkend="glossary-sequence">Sequence</glossterm> has a defined
- direction (usually increasing) and an interval step (usually 1).
- Whenever the <literal>NEXTVAL</literal> pseudo-column of a
- <glossterm linkend="glossary-sequence">Sequence</glossterm> is accessed,
- the current value is moved in the defined direction by the defined
- interval step, that value is returned to the invoking query,
- and the current value of the sequence is updated to reflect the new value.
- The value can be updated multiple times in a single query,
- the net effect being that each row selected will have a different value.
- Values taken from a
- <glossterm linkend="glossary-sequence">Sequence</glossterm> are never
- reverted, even in the case of a
- <glossterm linkend="glossary-rollback">Rollback</glossterm>, which means
- that the <glossterm linkend="glossary-sequence">Sequence</glossterm>
- will never generate the same number twice, which makes it useful for
- generating
- <glossterm linkend="glossary-primary-key">Primary Key</glossterm> values.
- </para>
- <para>
- For more information, see
- <xref linkend="sql-createsequence"/>.
+ 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>
--->
<glossentry id="glossary-shared-memory">
- <glossterm>Shared Memory</glossterm>
+ <glossterm>Shared memory</glossterm>
<glossdef>
<para>
<acronym>RAM</acronym> which is used by the processes common to an
@@ -1342,28 +1373,32 @@
</glossdef>
</glossentry>
+ <glossentry>
+ <glossterm>Standby (server)</glossterm>
+ <glosssee otherterm="glossary-replica" />
+ </glossentry>
+
<glossentry id="glossary-sql-object">
<glossterm>SQL Object</glossterm>
<glossdef>
<para>
- A <glossterm linkend="glossary-table">table</glossterm>,
- <glossterm linkend="glossary-view">view</glossterm>,
- <glossterm linkend="glossary-materialized-view">materialized view</glossterm>,
- <glossterm linkend="glossary-index">index</glossterm>,
- <glossterm linkend="glossary-constraint">constraint</glossterm>,
-<!-- XXX define sequence <glossterm linkend="glossary-sequence"> --> sequence,
- <glossterm linkend="glossary-function">function</glossterm>,
- <glossterm linkend="glossary-procedure">procedure</glossterm>,
- <glossterm linkend="glossary-trigger">trigger</glossterm>,
- data type, or operator. Every one of those SQL objects
- belong to exactly one <glossterm linkend="glossary-schema">Schema</glossterm>.
- </para>
- <para>
- There also exist SQL objects that do not belong to schemas; those include
- <glossterm linkend="glossary-extension">extensions</glossterm>,
- <glossterm linkend="glossary-cast">data type cases</glossterm>,
- and
- <glossterm linkend="glossary-foreign-data-wrapper">foreign data wrappers</glossterm>.
+ 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>.
+ <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>.
+ </para>
+ <para>
+ Most local objects belong to a specific
+ <glossterm linkend="glossary-schema">schema</glossterm> in their containing database.
+ There also exist local objects that do not belong to 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>.
</para>
<para>
For more information, see
@@ -1373,7 +1408,7 @@
</glossentry>
<glossentry id="glossary-sql-standard">
- <glossterm>SQL Standard</glossterm>
+ <glossterm>SQL standard</glossterm>
<glossdef>
<para>
A series of documents that define the <acronym>SQL</acronym> language.
@@ -1382,11 +1417,11 @@
</glossentry>
<glossentry id="glossary-stats-collector">
- <glossterm>Stats Collector</glossterm>
+ <glossterm>Stats collector</glossterm>
<glossdef>
<para>
This process collects statistical information about the
- <glossterm linkend="glossary-cluster">Cluster</glossterm>'s activities.
+ <glossterm linkend="glossary-instance">instance</glossterm>'s activities.
</para>
<para>
For more information, see
@@ -1396,22 +1431,21 @@
</glossentry>
<glossentry id="glossary-system-catalog">
- <glossterm>System Catalog</glossterm>
+ <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 each <glossterm linkend="glossary-database">database</glossterm>
- and the <glossterm linkend="glossary-global-sql-object">global SQL objects</glossterm>
- of the <glossterm linkend="glossary-cluster">cluster</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> that expose some
+ 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>
@@ -1431,7 +1465,7 @@
<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
+ <glossterm linkend="glossary-relation">relation</glossterm> in
<productname>PostgreSQL</productname>.
</para>
<para>
@@ -1461,7 +1495,7 @@
</glossentry>
<glossentry id="glossary-temporary-table">
- <glossterm>Temporary Table</glossterm>
+ <glossterm>Temporary table</glossterm>
<glossdef>
<para>
<glossterm linkend="glossary-table">Tables</glossterm> that exist either
@@ -1499,6 +1533,30 @@
</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 <firstterm>xid</firstterm>.
+ When stored on disk, xids are only 32-bits wide, so only
+ approximately four billion write transactions IDs can be generated;
+ to permit the system to run for longer than that would allow,
+ <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
+ <firstterm>epoch</firstterm> value is incremented by one.
+ In some contexts, both the epoch and xid values are
+ considered together as a single 64-bit value.
+ </para>
+ <para>
+ For more information, see
+ <xref linkend="datatype-oid"/>.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id="glossary-trigger">
<glossterm>Trigger</glossterm>
<glossdef>
@@ -1508,7 +1566,7 @@
<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
+ 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.
@@ -1535,7 +1593,7 @@
</glossentry>
<glossentry id="glossary-unique-constraint">
- <glossterm>Unique Constraint</glossterm>
+ <glossterm>Unique constraint</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
@@ -1577,7 +1635,7 @@
<glossterm>Update</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command used to modify
+ 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.
@@ -1621,7 +1679,7 @@
<para>
The process of removing outdated <glossterm linkend="glossary-tuple">tuple
versions</glossterm> from tables, and other closely related
- garbage-collection-like processing required by <productname>PostgreSQL</productname>'s
+ 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
@@ -1651,8 +1709,28 @@
</glossdef>
</glossentry>
+ <glossentry id="glossary-vm">
+ <glossterm>Visibility map (fork)</glossterm>
+ <glossdef>
+ <para>
+ A storage structure that keeps metadata about each data page
+ in a table's main storage space. 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>) indicate 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>
+ <glossterm>WAL archiver (process)</glossterm>
<glossdef>
<para>
A process that saves copies of <glossterm linkend="glossary-wal-file">WAL files</glossterm>
@@ -1667,7 +1745,7 @@
</glossentry>
<glossentry id="glossary-wal-file">
- <glossterm>WAL File</glossterm>
+ <glossterm>WAL file</glossterm>
<glossdef>
<para>
Also known as <firstterm>WAL segment</firstterm> or
@@ -1678,7 +1756,7 @@
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 are replayed to restore the system to the state as it was
+ changes is replayed to restore the system to the state as it was
before the crash.
</para>
<para>
@@ -1696,13 +1774,8 @@
</glossdef>
</glossentry>
- <glossentry>
- <glossterm>WAL</glossterm>
- <glosssee otherterm="glossary-wal" />
- </glossentry>
-
<glossentry id="glossary-wal-record">
- <glossterm>WAL Record</glossterm>
+ <glossterm>WAL record</glossterm>
<glossdef>
<para>
A low-level description of an individual data change.
@@ -1719,17 +1792,17 @@
</glossentry>
<glossentry>
- <glossterm>WAL Segment</glossterm>
+ <glossterm>WAL segment</glossterm>
<glosssee otherterm="glossary-wal-file" />
</glossentry>
<glossentry id="glossary-wal-writer">
- <glossterm>WAL Writer (process)</glossterm>
+ <glossterm>WAL writer (process)</glossterm>
<glossdef>
<para>
A process that writes <glossterm linkend="glossary-wal-record">WAL records</glossterm>
- from <glossterm id="linkend-shared-memory">shared memory</glossterm> to
- <glossterm id="linkend-wal-file">WAL files</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
@@ -1739,7 +1812,7 @@
</glossentry>
<glossentry id="glossary-window-function">
- <glossterm>Window Function</glossterm>
+ <glossterm>Window function</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-function">function</glossterm> whose
@@ -1759,7 +1832,7 @@
</glossentry>
<glossentry id="glossary-wal">
- <glossterm>Write-Ahead Log</glossterm>
+ <glossterm>Write-ahead log</glossterm>
<glossdef>
<para>
The journal that keeps track of the changes in the
Import Notes
Reply to msg id not found: CADkLMekHJd3zCoO96bADd4-QnEr++E19MRxuHn5qmJLQpb70Q@mail.gmail.comd66ee81c-551d-6bc0-0836-28b01e9b827f@2ndquadrant.com280f7b1e-2e81-5d0e-2589-b5ea6313ad74@purtz.de20200405220715.GA20664@alvherre.pgsql686e65ba48801791816771e993ff5eebe571fac9.camel@cybertec.at7b9b469e804777ac9df4d37716db935e@xs4all.nl
On Thu, May 14, 2020 at 08:00:17PM -0400, Alvaro Herrera wrote:
+ <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>. + A set of properties of database transactions intended to guarantee validity + in concurrent operation and even in event of errors, power failures, etc.
I would capitalize Consistency, Isolation, Durability, and say "These four
properties" or "This set of four properties" (althought that makes this sounds
more like a fun game of DBA jeopardy).
+ <glossterm>Background writer (process)</glossterm> <glossdef> <para> - A process that continuously writes dirty pages from + A process that continuously writes dirty
I don't like "continuously"
+ <glossterm linkend="glossary-data-page">data pages</glossterm> from
+ <glossentry id="glossary-bloat"> + <glossterm>Bloat</glossterm> + <glossdef> + <para> + Space in data pages which does not contain relevant data, + such as unused (free) space or outdated row versions.
"current row versions" instead of relevant ?
+ <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 get clean by being written down
say "They become clean when written to disk"
+ to disk. New pages, which initially exist in memory only, are also + dirty until written.
+ <glossentry id="glossary-fork"> + <glossterm>Fork</glossterm> + <glossdef> + <para> + Each of the separate segmented file sets that a relation stores its + data in. There exist a <firstterm>main fork</firstterm> and two secondary
"in which a relation's data is stored"
+ forks: the <glossterm linkend="glossary-fsm">free space map</glossterm> + <glossterm linkend="glossary-vm">visibility map</glossterm>.
missing "and" ?
+ <glossentry id="glossary-fsm"> + <glossterm>Free space map (fork)</glossterm> + <glossdef> + <para> + A storage structure that keeps metadata about each data page in a table's + main storage space.
s/in/of/
just say "main fork"?
The free space map entry for each space stores the
for each page ?
+ amount of free space that's available for future tuples, and is structured + so it is efficient to search for available space for a new tuple of a given + size.
..to be efficiently searched to find free space..
The heap is realized within - <glossterm linkend="glossary-file-segment">segment files</glossterm>. + <glossterm linkend="glossary-file-segment">segmented files</glossterm> + in the relation's <glossterm linkend="glossary-fork">main fork</glossterm>.
Hm, the files aren't segmented. Say "one or more file segments per relation"
+ There also exist local objects that do not belong to 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>.
Don't extensions have schemas ?
+ <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 <firstterm>xid</firstterm>.
abbreviated *as* xid
+ approximately four billion write transactions IDs can be generated; + to permit the system to run for longer than that would allow,
remove "would allow"
<para>
The process of removing outdated <glossterm linkend="glossary-tuple">tuple
versions</glossterm> from tables, and other closely related
actually tables or materialized views..
+ <glossentry id="glossary-vm"> + <glossterm>Visibility map (fork)</glossterm> + <glossdef> + <para> + A storage structure that keeps metadata about each data page + in a table's main storage space. The visibility map entry for
s/in/of/
main fork?
--
Justin
Applied all these suggestions, and made a few additional very small
edits, and pushed -- better to ship what we have now in beta1, but
further edits are still possible.
Other possible terms to define, including those from the tweet I linked
to and a couple more:
archive
availability
backup
composite type
common table expression
data type
domain
dump
export
fault tolerance
GUC
high availability
hot standby
LSN
restore
secondary server (?)
snapshot
transactions per second
Anybody want to try their hand at a tentative definition?
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
v3-0001-Review-of-the-glossary.patchtext/x-diff; charset=iso-8859-1Download
From 6cdbfd1d9f2d6c7fa815aab853a51f86b3650e11 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: Fri, 15 May 2020 13:04:11 -0400
Subject: [PATCH v3] Review of the glossary
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add some more terms, clarify some definitions, remove redundant terms,
move a couple of terms to keep alphabetical order.
Co-authored-by: Jürgen Purtz <juergen@purtz.de>
Co-authored-by: Erik Rijkers <er@xs4all.nl>
Co-authored-by: Laurenz Albe <laurenz.albe@cybertec.at>
Discussion: https://postgr.es/m/7b9b469e804777ac9df4d37716db935e@xs4all.nl
---
doc/src/sgml/acronyms.sgml | 2 +-
doc/src/sgml/glossary.sgml | 536 ++++++++++++++++++++++---------------
2 files changed, 316 insertions(+), 222 deletions(-)
diff --git a/doc/src/sgml/acronyms.sgml b/doc/src/sgml/acronyms.sgml
index f638665dc9..b05c065546 100644
--- a/doc/src/sgml/acronyms.sgml
+++ b/doc/src/sgml/acronyms.sgml
@@ -766,7 +766,7 @@
<term><acronym>XID</acronym></term>
<listitem>
<para>
- <link linkend="datatype-oid">Transaction Identifier</link>
+ <glossterm linkend="glossary-xid">Transaction identifier</glossterm>
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 8c6cb6e942..a1e8a595c8 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -7,8 +7,23 @@
</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</glossterm>
+ <glossterm>Aggregate function</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-function">function</glossterm> that
@@ -35,11 +50,15 @@
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>
</glossdef>
</glossentry>
<glossentry>
- <glossterm>Analytic Function</glossterm>
+ <glossterm>Analytic function</glossterm>
<glosssee otherterm="glossary-window-function" />
</glossentry>
@@ -106,8 +125,8 @@
<glossdef>
<para>
Process of an <glossterm linkend="glossary-instance">instance</glossterm>
- which act on behalf of <glossterm linkend="glossary-session">client sessions</glossterm>
- and handle their requests.
+ 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
@@ -118,7 +137,7 @@
</glossentry>
<glossentry id="glossary-background-worker">
- <glossterm>Background Worker (process)</glossterm>
+ <glossterm>Background worker (process)</glossterm>
<glossdef>
<para>
Process within an <glossterm linkend="glossary-instance">instance</glossterm>,
@@ -138,10 +157,11 @@
</glossentry>
<glossentry id="glossary-background-writer">
- <glossterm>Background Writer (process)</glossterm>
+ <glossterm>Background writer (process)</glossterm>
<glossdef>
<para>
- A process that continuously writes dirty pages from
+ A process 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>
@@ -155,6 +175,16 @@
</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-cast">
<glossterm>Cast</glossterm>
<glossdef>
@@ -190,7 +220,7 @@
</glossentry>
<glossentry id="glossary-check-constraint">
- <glossterm>Check Constraint</glossterm>
+ <glossterm>Check constraint</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
@@ -208,15 +238,6 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-checkpointer">
- <glossterm>Checkpointer (process)</glossterm>
- <glossdef>
- <para>
- A specialized process responsible for executing checkpoints.
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id="glossary-checkpoint">
<glossterm>Checkpoint</glossterm>
<glossdef>
@@ -244,6 +265,15 @@
</glossdef>
</glossentry>
+ <glossentry id="glossary-checkpointer">
+ <glossterm>Checkpointer (process)</glossterm>
+ <glossdef>
+ <para>
+ A specialized process responsible for executing checkpoints.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry>
<glossterm>Class (archaic)</glossterm>
<glosssee otherterm="glossary-relation" />
@@ -262,27 +292,6 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-cluster">
- <glossterm>Cluster</glossterm>
- <glossdef>
- <para>
- A group of <glossterm linkend="glossary-database">databases</glossterm> plus their
- <glossterm linkend="glossary-global-sql-object">global SQL objects</glossterm>. The
- <firstterm>cluster</firstterm> is managed by exactly one
- <glossterm linkend="glossary-instance">instance</glossterm>. A newly created
- Cluster will have three databases created automatically. They are
- <literal>template0</literal>, <literal>template1</literal>, and
- <literal>postgres</literal>. It is expected that an application will
- create one or more additional database aside from these three.
- </para>
- <para>
- (Don't confuse the <productname>PostgreSQL</productname>-specific term
- <glossterm linkend="glossary-cluster">Cluster</glossterm> with the SQL
- command <command>CLUSTER</command>).
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id="glossary-column">
<glossterm>Column</glossterm>
<glossdef>
@@ -363,7 +372,10 @@
<glossdef>
<para>
A restriction on the values of data allowed within a
- <glossterm linkend="glossary-table">Table</glossterm>.
+ <glossterm linkend="glossary-table">table</glossterm>,
+ or in attributes of a
+ <!-- XXX Should have term "domain". Need term "type" for that. -->
+ <firstterm>domain</firstterm>.
</para>
<para>
For more information, see
@@ -373,19 +385,19 @@
</glossentry>
<glossentry>
- <glossterm>Data Area</glossterm>
+ <glossterm>Data area</glossterm>
<glosssee otherterm="glossary-data-directory" />
</glossentry>
<glossentry id="glossary-data-directory">
- <glossterm>Data Directory</glossterm>
+ <glossterm>Data directory</glossterm>
<glossdef>
<para>
The base directory on the filesystem of a
<glossterm linkend="glossary-server">server</glossterm> that contains all
- data files and subdirectories associated with a
- <glossterm linkend="glossary-cluster">cluster</glossterm> with the
- exception of <glossterm linkend="glossary-tablespace">tablespaces</glossterm>.
+ data files and subdirectories associated with an
+ <glossterm linkend="glossary-instance">instance</glossterm> (with the
+ exception of <glossterm linkend="glossary-tablespace">tablespaces</glossterm>).
The environment variable <literal>PGDATA</literal> is commonly used to
refer to the
<glossterm linkend="glossary-data-directory">data directory</glossterm>.
@@ -416,15 +428,31 @@
</glossentry>
<glossentry>
- <glossterm>Database Server</glossterm>
+ <glossterm>Database server</glossterm>
<glosssee otherterm="glossary-instance" />
</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 a <acronym>SQL</acronym>
+ The internal representation of one value of an <acronym>SQL</acronym>
data type.
</para>
</glossdef>
@@ -434,7 +462,7 @@
<glossterm>Delete</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command which removes
+ 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>.
@@ -459,6 +487,11 @@
</glossdef>
</glossentry>
+ <glossentry>
+ <glossterm>Epoch</glossterm>
+ <glosssee otherterm="glossary-xid" />
+ </glossentry>
+
<glossentry id="glossary-extension">
<glossterm>Extension</glossterm>
<glossdef>
@@ -475,12 +508,13 @@
</glossentry>
<glossentry id="glossary-file-segment">
- <glossterm>File Segment</glossterm>
+ <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,
+ 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>
@@ -495,14 +529,14 @@
</glossentry>
<glossentry id="glossary-foreign-data-wrapper">
- <glossterm>Foreign Data Wrapper</glossterm>
+ <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
+ <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 table</glossterm>s.
+ <glossterm linkend="glossary-foreign-table">foreign tables</glossterm>.
</para>
<para>
For more information, see
@@ -512,7 +546,7 @@
</glossentry>
<glossentry id="glossary-foreign-key">
- <glossterm>Foreign Key</glossterm>
+ <glossterm>Foreign key</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
@@ -527,7 +561,7 @@
</glossentry>
<glossentry id="glossary-foreign-server">
- <glossterm>Foreign Server</glossterm>
+ <glossterm>Foreign server</glossterm>
<glossdef>
<para>
A named collection of
@@ -544,7 +578,7 @@
</glossentry>
<glossentry id="glossary-foreign-table">
- <glossterm>Foreign Table</glossterm>
+ <glossterm>Foreign table</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> which appears to have
@@ -564,6 +598,38 @@
</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</glossterm>
<glossdef>
@@ -579,28 +645,11 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-global-sql-object">
- <glossterm>Global SQL Object</glossterm>
- <glossdef>
- <para>
- <glossterm linkend="glossary-sql-object">SQL objects</glossterm> which do
- not belong to a specific
- <glossterm linkend="glossary-database">database</glossterm>.
- </para>
- <para>
- These objects are
- <glossterm linkend="glossary-role">roles</glossterm>,
- <glossterm linkend="glossary-tablespace">tablespaces</glossterm>,
- replication origins, and subscriptions for logical replication.
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id="glossary-grant">
<glossterm>Grant</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command that is used to allow
+ An <acronym>SQL</acronym> command that is used to allow
<glossterm linkend="glossary-user">users</glossterm> or
<glossterm linkend="glossary-role">role</glossterm> to access
specific objects within the <glossterm linkend="glossary-database">database</glossterm>.
@@ -619,8 +668,9 @@
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
- <glossterm linkend="glossary-file-segment">segment files</glossterm>.
+ The heap is realized within one of more
+ <glossterm linkend="glossary-file-segment">file segments</glossterm>
+ in the relation's <glossterm linkend="glossary-fork">main fork</glossterm>.
</para>
</glossdef>
</glossentry>
@@ -629,10 +679,11 @@
<glossterm>Host</glossterm>
<glossdef>
<para>
- A computer that communicates with other hosts over a network.
- This term can be used to refer to either a
- <glossterm linkend="glossary-client">client</glossterm>
- or a <glossterm linkend="glossary-server">server</glossterm>.
+ 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>
@@ -659,7 +710,7 @@
<glossterm>Insert</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command used to add new data into a
+ An <acronym>SQL</acronym> command used to add new data into a
<glossterm linkend="glossary-table">table</glossterm>.
</para>
<para>
@@ -673,27 +724,28 @@
<glossterm>Instance</glossterm>
<glossdef>
<para>
- An <glossterm>instance</glossterm> is a group of processes,
- its supporting <glossterm linkend="glossary-data-directory">storage space</glossterm>,
- plus their
- common <glossterm linkend="glossary-shared-memory">shared memory</glossterm>,
- running on a single <glossterm linkend="glossary-server">server</glossterm>.
- The <glossterm linkend="glossary-instance">instance</glossterm>
- handles all key features of a <acronym>DBMS</acronym>: read and write
- access to files and shared memory, assurance of
- the <acronym>ACID</acronym> paradigm, <acronym>MVCC</acronym>,
- <glossterm linkend="glossary-connection">connections</glossterm> to client programs, backup,
- recovery, replication, privileges, etc.
+ A set of databases and accompanying global SQL objects that are stored in
+ the same <glossterm linkend="glossary-data-directory">data directory</glossterm>
+ in a single <glossterm linkend="glossary-server">server</glossterm>.
+ If running, one
+ <glossterm linkend="glossary-postmaster">postmaster process</glossterm>
+ manages a group of backend and auxiliary processes that communicate
+ using a common <glossterm linkend="glossary-shared-memory">shared memory</glossterm>
+ area. 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>
- An <glossterm>instance</glossterm> manages exactly one
- <glossterm linkend="glossary-cluster">cluster</glossterm>.
+ 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 client processes,
+ privilege verification, crash recovery, replication, etc.
</para>
<para>
- Many <glossterm>instances</glossterm> can run on the same server as
- long as their <acronym>TCP/IP</acronym> ports do not conflict.
- Different instances on a server may use the
- same or different versions of <productname>PostgreSQL</productname>.
+ 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>
</glossdef>
</glossentry>
@@ -717,7 +769,7 @@
<glossterm>Join</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> keyword used in <command>SELECT</command> statements for
+ An <acronym>SQL</acronym> keyword used in <command>SELECT</command> statements for
combining data from multiple <glossterm linkend="glossary-relation">relations</glossterm>.
</para>
</glossdef>
@@ -748,7 +800,7 @@
</glossentry>
<glossentry id="glossary-log-file">
- <glossterm>Log File</glossterm>
+ <glossterm>Log file</glossterm>
<glossdef>
<para>
Log files contain human-readable text lines about events.
@@ -761,6 +813,29 @@
</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-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>
@@ -780,29 +855,6 @@
</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-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>
<glossterm>Master (server)</glossterm>
<glosssee otherterm="glossary-primary-server" />
@@ -831,7 +883,7 @@
</glossentry>
<glossentry id="glossary-materialized-view">
- <glossterm>Materialized View</glossterm>
+ <glossterm>Materialized view</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
@@ -869,8 +921,8 @@
<glossterm>Null</glossterm>
<glossdef>
<para>
- A concept of non-existence that is a central tenet of Relational
- Database Theory. It represents the absence of value.
+ 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>
@@ -881,7 +933,7 @@
</glossentry>
<glossentry id="glossary-parallel-query">
- <glossterm>Parallel Query</glossterm>
+ <glossterm>Parallel query</glossterm>
<glossdef>
<para>
The ability to handle parts of executing a
@@ -918,7 +970,7 @@
</glossentry>
<glossentry id="glossary-partitioned-table">
- <glossterm>Partitioned Table</glossterm>
+ <glossterm>Partitioned table</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
@@ -960,7 +1012,7 @@
</glossentry>
<glossentry id="glossary-primary-key">
- <glossterm>Primary Key</glossterm>
+ <glossterm>Primary key</glossterm>
<glossdef>
<para>
A special case of a
@@ -1011,7 +1063,7 @@
</glossentry>
<glossentry id="glossary-planner">
- <glossterm>Query Planner</glossterm>
+ <glossterm>Query planner</glossterm>
<glossdef>
<para>
The part of <productname>PostgreSQL</productname> that is devoted to
@@ -1034,7 +1086,7 @@
</glossentry>
<glossentry id="glossary-referential-integrity">
- <glossterm>Referential Integrity</glossterm>
+ <glossterm>Referential integrity</glossterm>
<glossdef>
<para>
A means of restricting data in one <glossterm linkend="glossary-relation">relation</glossterm>
@@ -1055,9 +1107,11 @@
<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>, and
+ <glossterm linkend="glossary-materialized-view">materialized views</glossterm>,
+ composite types, and
<glossterm linkend="glossary-index">indexes</glossterm> are all relations.
</para>
<para>
@@ -1068,7 +1122,7 @@
</glossentry>
<glossentry id="glossary-replica">
- <glossterm>Replica</glossterm>
+ <glossterm>Replica (server)</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-database">database</glossterm> that is paired
@@ -1098,12 +1152,13 @@
</glossentry>
<glossentry id="glossary-result-set">
- <glossterm>Result Set</glossterm>
+ <glossterm>Result set</glossterm>
<glossdef>
<para>
A data structure transmitted from a
<glossterm linkend="glossary-backend">backend process</glossterm> to
- client program upon the completion of a <acronym>SQL</acronym>
+ 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>, or
<command>DELETE</command> command if the <literal>RETURNING</literal>
@@ -1135,7 +1190,7 @@
<para>
A collection of access privileges to the
<glossterm linkend="glossary-database">instance</glossterm>.
- Roless are themselves a privilege that can be granted to other roles.
+ 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.
@@ -1170,7 +1225,7 @@
<glossterm>Savepoint</glossterm>
<glossdef>
<para>
- A special mark inside the sequence of steps in a
+ 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.
@@ -1186,13 +1241,15 @@
<glossterm>Schema</glossterm>
<glossdef>
<para>
- A schema is a namespace for <glossterm linkend="glossary-sql-object">SQL objects</glossterm>,
+ 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.
+ <glossterm linkend="glossary-database">database</glossterm>.
+ Each SQL object must reside in exactly one schema.
</para>
<para>
- The names of SQL objects of the same type in the same schema are enforced unique.
+ The names of SQL objects of the same type in the same schema are enforced
+ to be unique.
There is no restriction on reusing a name in multiple schemas.
</para>
<para>
@@ -1205,7 +1262,7 @@
</glossdef>
<glossdef>
<para>
- More generically, the term <firstterm>Schema</firstterm> is used to mean
+ 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
@@ -1264,7 +1321,10 @@
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 Virtual Machine.
+ 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>
@@ -1279,45 +1339,21 @@
</glossdef>
</glossentry>
-<!-- XXX we should have a much more concise definition
<glossentry id="glossary-sequence">
<glossterm>Sequence</glossterm>
<glossdef>
<para>
- A <glossterm linkend="glossary-database">Database</glossterm> object which
- represents the mathematical concept of a numerical integral sequence.
- It can be thought of as a <glossterm linkend="glossary-table">Table</glossterm>
- with exactly one <glossterm linkend="glossary-tuple">Row</glossterm> and
- one <glossterm linkend="glossary-column">Column</glossterm>. The
- value stored is known as the current value. A
- <glossterm linkend="glossary-sequence">Sequence</glossterm> has a defined
- direction (usually increasing) and an interval step (usually 1).
- Whenever the <literal>NEXTVAL</literal> pseudo-column of a
- <glossterm linkend="glossary-sequence">Sequence</glossterm> is accessed,
- the current value is moved in the defined direction by the defined
- interval step, that value is returned to the invoking query,
- and the current value of the sequence is updated to reflect the new value.
- The value can be updated multiple times in a single query,
- the net effect being that each row selected will have a different value.
- Values taken from a
- <glossterm linkend="glossary-sequence">Sequence</glossterm> are never
- reverted, even in the case of a
- <glossterm linkend="glossary-rollback">Rollback</glossterm>, which means
- that the <glossterm linkend="glossary-sequence">Sequence</glossterm>
- will never generate the same number twice, which makes it useful for
- generating
- <glossterm linkend="glossary-primary-key">Primary Key</glossterm> values.
- </para>
- <para>
- For more information, see
- <xref linkend="sql-createsequence"/>.
+ 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>
--->
<glossentry id="glossary-shared-memory">
- <glossterm>Shared Memory</glossterm>
+ <glossterm>Shared memory</glossterm>
<glossdef>
<para>
<acronym>RAM</acronym> which is used by the processes common to an
@@ -1342,28 +1378,32 @@
</glossdef>
</glossentry>
+ <glossentry>
+ <glossterm>Standby (server)</glossterm>
+ <glosssee otherterm="glossary-replica" />
+ </glossentry>
+
<glossentry id="glossary-sql-object">
<glossterm>SQL Object</glossterm>
<glossdef>
<para>
- A <glossterm linkend="glossary-table">table</glossterm>,
- <glossterm linkend="glossary-view">view</glossterm>,
- <glossterm linkend="glossary-materialized-view">materialized view</glossterm>,
- <glossterm linkend="glossary-index">index</glossterm>,
- <glossterm linkend="glossary-constraint">constraint</glossterm>,
-<!-- XXX define sequence <glossterm linkend="glossary-sequence"> --> sequence,
- <glossterm linkend="glossary-function">function</glossterm>,
- <glossterm linkend="glossary-procedure">procedure</glossterm>,
- <glossterm linkend="glossary-trigger">trigger</glossterm>,
- data type, or operator. Every one of those SQL objects
- belong to exactly one <glossterm linkend="glossary-schema">Schema</glossterm>.
- </para>
- <para>
- There also exist SQL objects that do not belong to schemas; those include
- <glossterm linkend="glossary-extension">extensions</glossterm>,
- <glossterm linkend="glossary-cast">data type cases</glossterm>,
- and
- <glossterm linkend="glossary-foreign-data-wrapper">foreign data wrappers</glossterm>.
+ 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>.
+ <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>.
+ </para>
+ <para>
+ Most local objects belong to a specific
+ <glossterm linkend="glossary-schema">schema</glossterm> in their containing database.
+ There also exist local objects that do not belong to 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>.
</para>
<para>
For more information, see
@@ -1373,7 +1413,7 @@
</glossentry>
<glossentry id="glossary-sql-standard">
- <glossterm>SQL Standard</glossterm>
+ <glossterm>SQL standard</glossterm>
<glossdef>
<para>
A series of documents that define the <acronym>SQL</acronym> language.
@@ -1382,11 +1422,11 @@
</glossentry>
<glossentry id="glossary-stats-collector">
- <glossterm>Stats Collector</glossterm>
+ <glossterm>Stats collector</glossterm>
<glossdef>
<para>
This process collects statistical information about the
- <glossterm linkend="glossary-cluster">Cluster</glossterm>'s activities.
+ <glossterm linkend="glossary-instance">instance</glossterm>'s activities.
</para>
<para>
For more information, see
@@ -1396,22 +1436,21 @@
</glossentry>
<glossentry id="glossary-system-catalog">
- <glossterm>System Catalog</glossterm>
+ <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 each <glossterm linkend="glossary-database">database</glossterm>
- and the <glossterm linkend="glossary-global-sql-object">global SQL objects</glossterm>
- of the <glossterm linkend="glossary-cluster">cluster</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> that expose some
+ 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>
@@ -1431,7 +1470,7 @@
<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
+ <glossterm linkend="glossary-relation">relation</glossterm> in
<productname>PostgreSQL</productname>.
</para>
<para>
@@ -1461,7 +1500,7 @@
</glossentry>
<glossentry id="glossary-temporary-table">
- <glossterm>Temporary Table</glossterm>
+ <glossterm>Temporary table</glossterm>
<glossdef>
<para>
<glossterm linkend="glossary-table">Tables</glossterm> that exist either
@@ -1481,6 +1520,21 @@
</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>
@@ -1499,6 +1553,30 @@
</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.
+ </para>
+ <para>
+ For more information, see
+ <xref linkend="datatype-oid"/>.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id="glossary-trigger">
<glossterm>Trigger</glossterm>
<glossdef>
@@ -1508,7 +1586,7 @@
<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
+ 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.
@@ -1535,7 +1613,7 @@
</glossentry>
<glossentry id="glossary-unique-constraint">
- <glossterm>Unique Constraint</glossterm>
+ <glossterm>Unique constraint</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
@@ -1577,7 +1655,7 @@
<glossterm>Update</glossterm>
<glossdef>
<para>
- A <acronym>SQL</acronym> command used to modify
+ 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.
@@ -1619,9 +1697,10 @@
<glossterm>Vacuum</glossterm>
<glossdef>
<para>
- The process of removing outdated <glossterm linkend="glossary-tuple">tuple
- versions</glossterm> from tables, and other closely related
- garbage-collection-like processing required by <productname>PostgreSQL</productname>'s
+ 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
@@ -1651,8 +1730,28 @@
</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>) indicate 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>
+ <glossterm>WAL archiver (process)</glossterm>
<glossdef>
<para>
A process that saves copies of <glossterm linkend="glossary-wal-file">WAL files</glossterm>
@@ -1667,7 +1766,7 @@
</glossentry>
<glossentry id="glossary-wal-file">
- <glossterm>WAL File</glossterm>
+ <glossterm>WAL file</glossterm>
<glossdef>
<para>
Also known as <firstterm>WAL segment</firstterm> or
@@ -1678,7 +1777,7 @@
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 are replayed to restore the system to the state as it was
+ changes is replayed to restore the system to the state as it was
before the crash.
</para>
<para>
@@ -1696,13 +1795,8 @@
</glossdef>
</glossentry>
- <glossentry>
- <glossterm>WAL</glossterm>
- <glosssee otherterm="glossary-wal" />
- </glossentry>
-
<glossentry id="glossary-wal-record">
- <glossterm>WAL Record</glossterm>
+ <glossterm>WAL record</glossterm>
<glossdef>
<para>
A low-level description of an individual data change.
@@ -1719,17 +1813,17 @@
</glossentry>
<glossentry>
- <glossterm>WAL Segment</glossterm>
+ <glossterm>WAL segment</glossterm>
<glosssee otherterm="glossary-wal-file" />
</glossentry>
<glossentry id="glossary-wal-writer">
- <glossterm>WAL Writer (process)</glossterm>
+ <glossterm>WAL writer (process)</glossterm>
<glossdef>
<para>
A process that writes <glossterm linkend="glossary-wal-record">WAL records</glossterm>
- from <glossterm id="linkend-shared-memory">shared memory</glossterm> to
- <glossterm id="linkend-wal-file">WAL files</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
@@ -1739,7 +1833,7 @@
</glossentry>
<glossentry id="glossary-window-function">
- <glossterm>Window Function</glossterm>
+ <glossterm>Window function</glossterm>
<glossdef>
<para>
A type of <glossterm linkend="glossary-function">function</glossterm> whose
@@ -1759,7 +1853,7 @@
</glossentry>
<glossentry id="glossary-wal">
- <glossterm>Write-Ahead Log</glossterm>
+ <glossterm>Write-ahead log</glossterm>
<glossdef>
<para>
The journal that keeps track of the changes in the
--
2.20.1
On 2020-05-15 19:26, Alvaro Herrera wrote:
Applied all these suggestions, and made a few additional very small
edits, and pushed -- better to ship what we have now in beta1, but
further edits are still possible.
I've gone through the glossary as committed and found some more small
things; patch attached.
Thanks,
Erik Rijkers
Show quoted text
Other possible terms to define, including those from the tweet I linked
to and a couple more:archive
availability
backup
composite type
common table expression
data type
domain
dump
export
fault tolerance
GUC
high availability
hot standby
LSN
restore
secondary server (?)
snapshot
transactions per secondAnybody want to try their hand at a tentative definition?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
glossary-20200516.sgml.difftext/x-diff; name=glossary-20200516.sgml.diffDownload
--- doc/src/sgml/glossary.sgml.orig 2020-05-16 23:30:01.132290237 +0200
+++ doc/src/sgml/glossary.sgml 2020-05-16 23:38:35.643371310 +0200
@@ -67,7 +67,7 @@
<glossdef>
<para>
In reference to a <glossterm linkend="glossary-datum">datum</glossterm>:
- the fact that its value that cannot be broken down into smaller
+ the fact that its value cannot be broken down into smaller
components.
</para>
</glossdef>
@@ -360,7 +360,7 @@
<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 transaction is automatically
+ 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>
@@ -649,8 +649,8 @@
<glossterm>Grant</glossterm>
<glossdef>
<para>
- An <acronym>SQL</acronym> command that is used to allow
- <glossterm linkend="glossary-user">users</glossterm> or
+ 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>
@@ -887,7 +887,7 @@
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
- defined in the same way that a a <glossterm linkend="glossary-view">view</glossterm>
+ defined in the same way that a <glossterm linkend="glossary-view">view</glossterm>
is, 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>, or
@@ -962,7 +962,7 @@
<glossdef>
<para>
In reference to a <glossterm linkend="glossary-window-function">window function</glossterm>:
- a partition is a user-defined criteria that identifies which neighboring
+ a partition is a user-defined criterion that identifies which neighboring
<glossterm linkend="glossary-tuple">rows</glossterm> can be considered by the
function.
</para>
@@ -1446,8 +1446,8 @@
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
+ 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
@@ -1739,7 +1739,7 @@
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>) indicate that all tuples
+ (<literal>all-frozen</literal>) indicates that all tuples
in the page are marked frozen.
</para>
</glossdef>
@@ -1755,7 +1755,7 @@
<glossdef>
<para>
A process that saves copies of <glossterm linkend="glossary-wal-file">WAL files</glossterm>
- for the purposes of creating backups or keeping
+ for the purpose of creating backups or keeping
<glossterm linkend="glossary-replica">replicas</glossterm> current.
</para>
<para>
@@ -1777,7 +1777,7 @@
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 as it was
+ changes is replayed to restore the system to the state it was in
before the crash.
</para>
<para>
On 2020-May-16, Erik Rijkers wrote:
On 2020-05-15 19:26, Alvaro Herrera wrote:
Applied all these suggestions, and made a few additional very small
edits, and pushed -- better to ship what we have now in beta1, but
further edits are still possible.I've gone through the glossary as committed and found some more small
things; patch attached.
All pushed! Many thanks,
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 15.05.20 02:00, Alvaro Herrera wrote:
Thanks everybody. I have compiled together all the suggestions and the
result is in the attached patch. Some of it is of my own devising.* I changed "instance", and made "cluster" be mostly a synonym of that.
In my understanding, "instance" and "cluster" should be different
things, not only synonyms. "instance" can be the term for permanently
fluctuating objects (processes and RAM) and "cluster" can denote the
more static objects (directories and files). What do you think? If you
agree, I would create a patch.
* I removed "global SQL object" and made "SQL object" explain it.
+1., but see the (huge) different spellings in patch.
bloat: changed 'current row' to 'relevant row' because not only the
youngest one is relevant (non-bloat).
data type casts: Are you sure that they are global? In pg_cast
'relisshared' is 'false'.
--
J�rgen Purtz
Attachments:
0002-glossfixes-purtz.patchtext/x-patch; charset=UTF-8; name=0002-glossfixes-purtz.patchDownload
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 8bb1ea5d87..75f0dc9a8c 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -179,7 +179,7 @@
<glossterm>Bloat</glossterm>
<glossdef>
<para>
- Space in data pages which does not contain current row versions,
+ Space in data pages which does not contain relevant row versions,
such as unused (free) space or outdated row versions.
</para>
</glossdef>
@@ -1388,23 +1388,27 @@
<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>.
+ command. Most objects are specific to one schema within
+ one database, and are commonly
+ known as <firstterm>local SQL objects</firstterm>.
+ </para>
+ <para>
+ Some of the SQL objects do not belong to a single schema but
+ are known in all schemas of a database. Examples are
+ <glossterm linkend="glossary-extension">extensions</glossterm> like
+ <glossterm linkend="glossary-foreign-data-wrapper">foreign data wrappers</glossterm>, and
+ <glossterm linkend="glossary-cast">data type casts</glossterm>.
+ </para>
+ <para>
+ Some others even belong to the complete cluster and are
+ known in all databases and all its schemas.
<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>.
+ all <firstterm>database names</firstterm> exist
+ entirely outside of any specific database.
+ They are called <firstterm>global SQL objects</firstterm>.
</para>
- <para>
- Most local objects belong to a specific
- <glossterm linkend="glossary-schema">schema</glossterm> in their containing database.
- There also exist local objects that do not belong to 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>.
- </para>
<para>
For more information, see
<xref linkend="manage-ag-overview"/>.
On 2020-May-17, J�rgen Purtz wrote:
On 15.05.20 02:00, Alvaro Herrera wrote:
Thanks everybody. I have compiled together all the suggestions and the
result is in the attached patch. Some of it is of my own devising.* I changed "instance", and made "cluster" be mostly a synonym of that.
In my understanding, "instance" and "cluster" should be different things,
not only synonyms. "instance" can be the term for permanently fluctuating
objects (processes and RAM) and "cluster" can denote the more static objects
(directories and files). What do you think? If you agree, I would create a
patch.
I don't think that's the general understanding of those terms. For all
I know, they *are* synonyms, and there's no specific term for "the
fluctuating objects" as you call them. The instance is either running
(in which case there are processes and RAM) or it isn't.
* I removed "global SQL object" and made "SQL object" explain it.
+1., but see the (huge) different spellings in patch.
This seems a misunderstanding of what "local" means. Any object that
exists in a database is local, regardless of whether it exists in a
schema or not. "Extensions" is one type of object that does not belong
in a schema. "Foreign data wrapper" is another type of object that does
not belong in a schema. Same with data type casts. They are *not*
global objects.
bloat: changed 'current row' to 'relevant row' because not only the youngest
one is relevant (non-bloat).
Hm. TBH I'm not sure of this term at all. I think we sometimes use the
term "bloat" to talk about the dead rows only, ignoring the free space.
data type casts: Are you sure that they are global? In pg_cast 'relisshared'
is 'false'.
I'm not saying they're global. I'm saying they're outside schemas.
Maybe this definition needs more rewording, if this bit is unclear.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 17.05.20 08:51, Alvaro Herrera wrote:
Any object that
exists in a database is local, regardless of whether it exists in a
schema or not.
This implies that the term "local" is unnecessary, just call them "SQL
object".
"Extensions" is one type of object that does not belong
in a schema. "Foreign data wrapper" is another type of object that does
not belong in a schema. ... They are*not*
global objects.
postgres_fdw is a module among many others. It's only an example for
"extensions" and has no different nature. Yes, they are not global SQL
objects because they don't belong to the cluster.
In summary we have 3 types of objects: belonging to a schema, to a
database, or to the cluster (global). Maybe, we can avoid the use of the
different names 'local SQL object' and 'global SQL object' at all and
just call them 'SQL object'. 'global SQL object' is used only once. We
could rephrase "A set of databases and accompanying global SQL objects
... " to "A set of databases and accompanying SQL objects, which exists
at the cluster level, ... "
TBH I'm not sure of this term at all. I think we sometimes use the
term "bloat" to talk about the dead rows only, ignoring the free space.
That's a good example for the necessity of the glossary. Currently we
don't have a common understanding about all of our used terms. The
glossary shall fix that and give a mandatory definition - after a
clearing discussion.
--
Jürgen Purtz
On 17.05.20 08:51, Alvaro Herrera wrote:
On 15.05.20 02:00, Alvaro Herrera wrote:
Thanks everybody. I have compiled together all the suggestions and the
result is in the attached patch. Some of it is of my own devising.* I changed "instance", and made "cluster" be mostly a synonym of that.
In my understanding, "instance" and "cluster" should be different things,
not only synonyms. "instance" can be the term for permanently fluctuating
objects (processes and RAM) and "cluster" can denote the more static objects
(directories and files). What do you think? If you agree, I would create a
patch.I don't think that's the general understanding of those terms. For all
I know, they*are* synonyms, and there's no specific term for "the
fluctuating objects" as you call them. The instance is either running
(in which case there are processes and RAM) or it isn't.
We have the basic tools "initdb — create a new PostgreSQL database
cluster" which affects nothing but files, and we have "pg_ctl —
initialize, start, stop, or control a PostgreSQL server" which -
directly - affects nothing but processes and RAM. (Here the term
"server" collides with new definitions in the glossary. But that's
another story.)
--
Jürgen Purtz
On 2020-05-17 08:51, Alvaro Herrera wrote:
On 2020-May-17, Jürgen Purtz wrote:
On 15.05.20 02:00, Alvaro Herrera wrote:
Thanks everybody. I have compiled together all the suggestions and the
* I changed "instance", and made "cluster" be mostly a synonym of that.
In my understanding, "instance" and "cluster" should be different
things,I don't think that's the general understanding of those terms. For all
I know, they *are* synonyms, and there's no specific term for "the
fluctuating objects" as you call them. The instance is either running
(in which case there are processes and RAM) or it isn't.
For what it's worth, I've also always understood 'instance' as 'a
running database'. I admit it might be a left-over from my oracle
years:
https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT601
There, 'instance' clearly refers to a running database. When that
database is stopped, it ceases to be an instance. I've always
understood this to be the same for the PostgreSQL 'instance'. Once
stopped, it is no longer an instance, but it is, of course, still a
cluster.
I know, we don't have to do the same as Oracle, but clearly it's going
to be an ongoing source of misunderstanding if we define such a
high-level term differently.
Erik Rijkers
On 2020-May-17, Erik Rijkers wrote:
On 2020-05-17 08:51, Alvaro Herrera wrote:
I don't think that's the general understanding of those terms. For all
I know, they *are* synonyms, and there's no specific term for "the
fluctuating objects" as you call them. The instance is either running
(in which case there are processes and RAM) or it isn't.For what it's worth, I've also always understood 'instance' as 'a running
database'. I admit it might be a left-over from my oracle years:https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT601
There, 'instance' clearly refers to a running database. When that database
is stopped, it ceases to be an instance.
I've never understood it that way, but I'm open to having my opinion on
it changed. So let's discuss it and maybe gather opinions from others.
I think the terms under discussion are just
* cluster
* instance
* server
We don't have "host" (I just made it a synonym for server), but perhaps
we can add that too, if it's useful. It would be good to be consistent
with historical Postgres usage, such as the initdb usage of "cluster"
etc.
Perhaps we should not only define what our use of each term is, but also
explain how each term is used outside PostgreSQL and highlight the
differences. (This would be particularly useful for "cluster" ISTM.)
It seems difficult to get this sorted out before beta1, but there's
still time before the glossary is released.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 17.05.20 17:28, Alvaro Herrera wrote:
On 2020-May-17, Erik Rijkers wrote:
On 2020-05-17 08:51, Alvaro Herrera wrote:
I don't think that's the general understanding of those terms. For all
I know, they*are* synonyms, and there's no specific term for "the
fluctuating objects" as you call them. The instance is either running
(in which case there are processes and RAM) or it isn't.For what it's worth, I've also always understood 'instance' as 'a running
database'. I admit it might be a left-over from my oracle years:https://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT601
There, 'instance' clearly refers to a running database. When that database
is stopped, it ceases to be an instance.I've never understood it that way, but I'm open to having my opinion on
it changed. So let's discuss it and maybe gather opinions from others.I think the terms under discussion are just
* cluster
* instance
* serverWe don't have "host" (I just made it a synonym for server), but perhaps
we can add that too, if it's useful. It would be good to be consistent
with historical Postgres usage, such as the initdb usage of "cluster"
etc.Perhaps we should not only define what our use of each term is, but also
explain how each term is used outside PostgreSQL and highlight the
differences. (This would be particularly useful for "cluster" ISTM.)
In fact, we have reached a point where we don't have a common
understanding of a group of terms. I'm sure that we will meet some more
situations like this in the future. Such discussions, subsequent
decisions, and implementations in the docs are necessary to gain a solid
foundation - primarily for newcomers (what is my first motivation) as
well as for more complex discussions among experts. Obviously, each of
us will include his previous understanding of terms. But we also should
be open to sometimes revise old terms.
Here are my two cents.
cluster/instance: PG (mainly) consists of a group of processes that
commonly act on shared buffers. The processes are very closely related
to each other and with the buffers. They exist altogether or not at all.
They use a common initialization file and are incarnated by one command.
Everything exists solely in RAM and therefor has a fluctuating nature.
In summary: they build a unit and this unit needs to have a name of
itself. In some pages we used to use the term *instance* - sometimes in
extended forms: *database instance*, *PG instance*, *standby instance*,
*standby server instance*, *server instance*, or *remote instance*. For
me, the term *instance* makes sense, the extensions *standby instance*
and *remote instance* in their context too.
The next essential component is the data itself. It is organized as a
group of databases plus some common management information (global,
pg_wal, pg_xact, pg_tblspc, ...). The complete data must be treated as a
whole because the management information concerns all databases. Its
nature is different from the processes and shared buffers. Of course,
its content changes, but it has a steady nature. It even survives a
'power down'. There is one command to instantiate a new incarnation of
the directory structure and all files. In summary, it's something of its
own and should have its own name. 'database' is not possible because it
consists of databases and other things. My favorite is *cluster*;
*database cluster* is also possible.
server/host: We need a term to describe the underlying hardware
respectively the virtual machine or container, where PG is running. I
suggest to use both *server* and *host*. In computer science, both have
their eligibility and are widely used. Everybody understands
*client/server architecture* or *host* in TCP/IP configuration. We
cannot change such matter of course. I suggest to use both depending on
the context, but with the same meaning: "real hardware, a container, or
a virtual machine".
--
Jürgen Purtz
(PS: I added the docs mailing list)
On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
cluster/instance: PG (mainly) consists of a group of processes that commonly
act on shared buffers. The processes are very closely related to each other
and with the buffers. They exist altogether or not at all. They use a common
initialization file and are incarnated by one command. Everything exists
solely in RAM and therefor has a fluctuating nature. In summary: they build
a unit and this unit needs to have a name of itself. In some pages we used
to use the term *instance* - sometimes in extended forms: *database instance*,
*PG instance*, *standby instance*, *standby server instance*, *server instance*,
or *remote instance*. For me, the term *instance* makes sense, the extensions
*standby instance* and *remote instance* in their context too.
FWIW, I feel somewhat like Alvaro on that point; I use those terms synonymously,
perhaps distinguishing between a "started cluster" and a "stopped cluster".
After all, "cluster" refers to "a cluster of databases", which are there, regardless
if you start the server or not.
The term "cluster" is unfortunate, because to most people it suggests a group of
machines, so the term "instance" is better, but that ship has sailed long ago.
The static part of a cluster to me is the "data directory".
server/host: We need a term to describe the underlying hardware respectively
the virtual machine or container, where PG is running. I suggest to use both
*server* and *host*. In computer science, both have their eligibility and are
widely used. Everybody understands *client/server architecture* or *host* in
TCP/IP configuration. We cannot change such matter of course. I suggest to
use both depending on the context, but with the same meaning: "real hardware,
a container, or a virtual machine".
On this I have a strong opinion because of my Unix mindset.
"machine" and "host" are synonyms, and it doesn't matter to the database if they
are virtualized or not. You can always disambiguate by adding "virtual" or "physical".
A "server" is a piece of software that responds to client requests, never a machine.
In my book, this is purely Windows jargon. The term "client-server architecture"
that you quote emphasized that.
Perhaps "machine" would be the preferable term, because "host" is more prone to
misunderstandings (except in a networking context).
Yours,
Laurenz Albe
I think there needs to be a careful analysis of the language and a formal
effort to stabilise it for the future.
In the context of, say, an Oracle T series, which is partitioned into
multiple domains (virtual machines) in it, each
of these has multiple CPUs, and can run an instance of the OS which hosts
multiple virtual instances
of the same or different OSes. Som domains might do this while others do
not!
A host could be a domain, one of many virtual machines, or it could be one
of many hosts on that VM
but even these hosts could be virtual machines that each runs several
virtual servers!
Of course, PostgreSQL can run on any tier of this regime, but the
documentation at least needs to be consistent
about language.
A "machine" should probably refer to hardware, although I would accept that
a domain might count as "virtual
hardware" while a host should probably refer to a single instance of OS.
Of course it is possible for a single instance of OS to run multiple
instances of PostgreSQL, and people do this. (I have
in the past).
Slightly more confusingly, it would appear possible for a single instance
of an OS to have multiple IP addresses
and if there are multiple instances of PostgreSQL, they may serve different
IP Addresses uniquely, or
share them. I think this case suggests that a host probably best describes
an OS instance. I might be wrong.
The word "server" might be an instance of any of the above, or a waiter
with a bowl of soup. It is best
reserved for situations where clarity is not required.
If you are new to all this, I am sure it is very confusing, and
inconsistent language is not going to help.
Andrew
AFAICT
On Tue, 19 May 2020 at 07:17, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
Show quoted text
On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
cluster/instance: PG (mainly) consists of a group of processes that
commonly
act on shared buffers. The processes are very closely related to each
other
and with the buffers. They exist altogether or not at all. They use a
common
initialization file and are incarnated by one command. Everything exists
solely in RAM and therefor has a fluctuating nature. In summary: theybuild
a unit and this unit needs to have a name of itself. In some pages we
used
to use the term *instance* - sometimes in extended forms: *database
instance*,
*PG instance*, *standby instance*, *standby server instance*, *server
instance*,
or *remote instance*. For me, the term *instance* makes sense, the
extensions
*standby instance* and *remote instance* in their context too.
FWIW, I feel somewhat like Alvaro on that point; I use those terms
synonymously,
perhaps distinguishing between a "started cluster" and a "stopped cluster".
After all, "cluster" refers to "a cluster of databases", which are there,
regardless
if you start the server or not.The term "cluster" is unfortunate, because to most people it suggests a
group of
machines, so the term "instance" is better, but that ship has sailed long
ago.The static part of a cluster to me is the "data directory".
server/host: We need a term to describe the underlying hardware
respectively
the virtual machine or container, where PG is running. I suggest to use
both
*server* and *host*. In computer science, both have their eligibility
and are
widely used. Everybody understands *client/server architecture* or
*host* in
TCP/IP configuration. We cannot change such matter of course. I suggest
to
use both depending on the context, but with the same meaning: "real
hardware,
a container, or a virtual machine".
On this I have a strong opinion because of my Unix mindset.
"machine" and "host" are synonyms, and it doesn't matter to the database
if they
are virtualized or not. You can always disambiguate by adding "virtual"
or "physical".A "server" is a piece of software that responds to client requests, never
a machine.
In my book, this is purely Windows jargon. The term "client-server
architecture"
that you quote emphasized that.Perhaps "machine" would be the preferable term, because "host" is more
prone to
misunderstandings (except in a networking context).Yours,
Laurenz Albe
On 2020-05-19 08:17, Laurenz Albe wrote:
The term "cluster" is unfortunate, because to most people it suggests a group of
machines, so the term "instance" is better, but that ship has sailed long ago.
I don't see what would stop us from renaming some things, with some care.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 19.05.20 08:17, Laurenz Albe wrote:
On Mon, 2020-05-18 at 18:08 +0200, Jürgen Purtz wrote:
cluster/instance: PG (mainly) consists of a group of processes that commonly
act on shared buffers. The processes are very closely related to each other
and with the buffers. They exist altogether or not at all. They use a common
initialization file and are incarnated by one command. Everything exists
solely in RAM and therefor has a fluctuating nature. In summary: they build
a unit and this unit needs to have a name of itself. In some pages we used
to use the term *instance* - sometimes in extended forms: *database instance*,
*PG instance*, *standby instance*, *standby server instance*, *server instance*,
or *remote instance*. For me, the term *instance* makes sense, the extensions
*standby instance* and *remote instance* in their context too.FWIW, I feel somewhat like Alvaro on that point; I use those terms synonymously,
perhaps distinguishing between a "started cluster" and a "stopped cluster".
After all, "cluster" refers to "a cluster of databases", which are there, regardless
if you start the server or not.The term "cluster" is unfortunate, because to most people it suggests a group of
machines, so the term "instance" is better, but that ship has sailed long ago.The static part of a cluster to me is the "data directory".
cluster/instance: The different nature (static/dynamic) of what I call
"cluster" and "instance" as well as the existence of the two commands
"initdb — create a new PostgreSQL database cluster" and "pg_ctl —
initialize, start, stop, or control a PostgreSQL server" confirms me in
my opinion that we need two different terms for them. Those two terms
shall not be synonym to each other, they label distinct things. If
people prefer "data directory" instead of "cluster", this is ok for me.
There are situations where we need a single term for both of them.
"Instance and its data directory" or "Instance and its cluster" are too
wordy. In many cases we use "database server" or "server" in this sense.
Imo "Server" is too short and ambiguous. "database server", the plural
form "databases server", or the new term "cluster server", which is more
accurate, would be ok for me. (Similar to "server", the term "cluster"
is also used in many different contexts - but only outside of the PG
world; within our context "cluster" is not ambiguous.)
server/host: We need a term to describe the underlying hardware respectively
the virtual machine or container, where PG is running. I suggest to use both
*server* and *host*. In computer science, both have their eligibility and are
widely used. Everybody understands *client/server architecture* or *host* in
TCP/IP configuration. We cannot change such matter of course. I suggest to
use both depending on the context, but with the same meaning: "real hardware,
a container, or a virtual machine".On this I have a strong opinion because of my Unix mindset.
"machine" and "host" are synonyms, and it doesn't matter to the database if they
are virtualized or not. You can always disambiguate by adding "virtual" or "physical".A "server" is a piece of software that responds to client requests, never a machine.
In my book, this is purely Windows jargon. The term "client-server architecture"
that you quote emphasized that.Perhaps "machine" would be the preferable term, because "host" is more prone to
misunderstandings (except in a networking context).
server/host: I agree that we are not interested in the question whether
there is real hardware or any virtualization container. We are even not
interested in the operating system. Our primary concern is the existence
of a port of the Internet Protocol. But is the term "server" appropriate
to name an IP-port? Additionally, "server" is used for other meanings:
a) the previously mentioned "database server" b) a (virtual) machine:
"server-side", "... the file ... loaded by the server ..." c) binaries
"... the server must be built with SSL support ..." d) whenever it seems
to be appropriate: "standby server", "... the server parses query ...",
"server configuration", "server process".
Because of its ambiguous usage, the definition of "server" must clarify
the allowed meanings. What's about:
--
server: Depending on the context, the term *server* denotes:
* An IP-port which is offered by any OS. ?????
* A - possibly virtualized - machine
* An abbreviation for the slightly longer term "database(s)/cluster
server" ??? this will support the readability, but not the clarity ???
* More ?
--
The term "host" is used mainly for IP configuration "host name", "host
address" and in the context of compiling "host language", "host
variable". These are clear situations and can be defined easily.
On Wed, 2020-05-20 at 13:17 +0200, Jürgen Purtz wrote:
FWIW, I feel somewhat like Alvaro on that point; I use those terms synonymously,
perhaps distinguishing between a "started cluster" and a "stopped cluster".
After all, "cluster" refers to "a cluster of databases", which are there, regardless
if you start the server or not.The term "cluster" is unfortunate, because to most people it suggests a group of
machines, so the term "instance" is better, but that ship has sailed long ago.The static part of a cluster to me is the "data directory".
cluster/instance: The different nature (static/dynamic) of what I
call "cluster" and "instance" as well as the existence of the two
commands "initdb — create a new PostgreSQL database cluster" and
"pg_ctl — initialize, start, stop, or control a PostgreSQL server"
confirms me in my opinion that we need two different terms for
them.
I think that the "pg_ctl" example does not apply:
It does not talk about starting the cluster, but about starting the server process,
that is "server" in the way I understand it.
There are situations where we need a single term for both of
them. "Instance and its data directory" or "Instance and its
cluster" are too wordy. In many cases we use "database server" or
"server" in this sense. Imo "Server" is too short and ambiguous.
"database server", the plural form "databases server", or the new
term "cluster server", which is more accurate, would be ok for me.
(Similar to "server", the term "cluster" is also used in many
different contexts - but only outside of the PG world; within our
context "cluster" is not ambiguous.)
That does not feel right to me.
"cluster server", ouch. "databases server", ouch as well.
I never felt the term "cluster" was unclear in these contexts.
Sometimes it means "data directory", sometimes it is used for "server process",
but I think few people would think one cound connect to a data directory
or create a process in a directory (initdb).
I think clarity is a Good Thing, but it can be overdone.
server/host: We need a term to describe the underlying hardware respectively
the virtual machine or container, where PG is running. I suggest to use both
*server* and *host*. In computer science, both have their eligibility and are
widely used. Everybody understands *client/server architecture* or *host* in
TCP/IP configuration. We cannot change such matter of course. I suggest to
use both depending on the context, but with the same meaning: "real hardware,
a container, or a virtual machine".On this I have a strong opinion because of my Unix mindset.
"machine" and "host" are synonyms, and it doesn't matter to the database if they
are virtualized or not. You can always disambiguate by adding "virtual" or "physical".A "server" is a piece of software that responds to client requests, never a machine.
In my book, this is purely Windows jargon. The term "client-server architecture"
that you quote emphasized that.Perhaps "machine" would be the preferable term, because "host" is more prone to
misunderstandings (except in a networking context).server/host: I agree that we are not interested in the question
whether there is real hardware or any virtualization container. We
are even not interested in the operating system. Our primary
concern is the existence of a port of the Internet Protocol. But
is the term "server" appropriate to name an IP-port? Additionally,
"server" is used for other meanings: a) the previously mentioned
"database server" b) a (virtual) machine: "server-side", "... the
file ... loaded by the server ..." c) binaries "... the server
must be built with SSL support ..." d) whenever it seems to be
appropriate: "standby server", "... the server parses query ...",
"server configuration", "server process".
You are most thorough :^)
Because of its ambiguous usage, the definition of "server" must
clarify the allowed meanings. What's about:server: Depending on the context, the term *server* denotes:
An IP-port which is offered by any OS. ?????
A port is a server? No way.
A - possibly virtualized - machine
It might be good to disambiguate that, but I don't think that the PostgreSQL
documentation should use the word "server" to mean "machine".
An abbreviation for the slightly longer term
"database(s)/cluster server" ??? this will support the
readability, but not the clarity ???
"Server" is short for "database server" and is a set of processes that listen
for and handle incoming database client requests.
I think that covers all the meanings you quoted from the documentation,
except c), where it is used as shorthand for "server executable".
Yours,
Laurenz Albe
On 17.05.20 17:28, Alvaro Herrera wrote:
I think the terms under discussion are just
* cluster
* instance
* server
Despite the short period of its existence the glossary achieved some
importance, see:
/messages/by-id/b8e12875ebec9e6d3107df5fa1129e1e@postgrespro.ru
. We have to be careful with publications. It's not acceptable that we
change definitions from release to release. Therefore IMO we should mark
or even ignore such terms for which we cannot reach consensus.
Can you agree to the following definitions? If no, we can alternatively
formulate for each of them: "Under discussion - currently not defined".
My proposals are inspired by chapter 2.2 Concepts: "Tables are grouped
into databases, and a collection of databases managed by a single
PostgreSQL server instance constitutes a database cluster."
- "Database" (No change to existing definition): "A named collection of
SQL objects."
- "Database Cluster", "Cluster" (New definition and rearrangements of
some sentences): "A collection of related databases, and their common
static and dynamic meta-data.
This term is sometimes used to refer to an instance.
(Don't confuse the term CLUSTER with the SQL command CLUSTER.)"
- "Data Directory" (Replaced 'instance' by 'cluster'): "The base
directory on the filesystem of a server that contains all data files and
subdirectories associated with a cluster (with the exception of
tablespaces). The environment variable PGDATA is commonly used to refer
to the data directory.
A cluster's storage space comprises the data directory plus any
additional tablespaces.
For more information, see Section 68.1."
- "Database Server", "Instance" (Major changes): "A group of backend and
auxiliary processes that communicate using a common shared memory area.
One postmaster process manages the instance; one instance manages
exactly one cluster with all its databases. Many instances can run on
the same server as long as their TCP ports do not conflict.
The instance handles all key features of a DBMS: read and write access
to files and shared memory, assurance of the ACID properties,
connections to client processes, privilege verification, crash recovery,
replication, etc."
- "Server" (No change to existing definition): "A computer on which
PostgreSQL instances run. The term server denotes real hardware, a
container, or a virtual machine.
This term is sometimes used to refer to an instance or to a host."
- "Host" (No change to existing definition): "A computer that
communicates with other computers over a network. This is sometimes used
as a synonym for server. It is also used to refer to a computer where
client processes run."
--
Jürgen Purtz
On 2020-Jun-09, J�rgen Purtz wrote:
Can you agree to the following definitions? If no, we can alternatively
formulate for each of them: "Under discussion - currently not defined". My
proposals are inspired by chapter 2.2 Concepts: "Tables are grouped into
databases, and a collection of databases managed by a single PostgreSQL
server instance constitutes a database cluster."
After sleeping on it a few more times, I don't oppose the idea of making
"instance" be the running state and "database cluster" the on-disk stuff
that supports the instance. Here's a patch that does things pretty much
along the lines you suggested.
I made small adjustments to "SQL objects":
* SQL objects in schemas were said to have their names unique in the
schema, but we failed to say anything about names of objects not in
schemas and global objects. Added that.
* Had example object types for global objects and objects not in
schemas, but no examples for objects in schemas. Added that.
Some programs whose output we could tweak per this:
pg_ctl
pg_ctl is a utility to initialize, start, stop, or control a PostgreSQL server.
-D, --pgdata=DATADIR location of the database storage area
to:
pg_ctl is a utility to initialize or control a PostgreSQL database cluster.
-D, --pgdata=DATADIR location of the database directory
pg_basebackup:
pg_basebackup takes a base backup of a running PostgreSQL server.
to:
pg_basebackup takes a base backup of a PostgreSQL instance.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
glossary.patchtext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 25b03f3b37..e29b55e5ac 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -395,15 +395,15 @@
<para>
The base directory on the filesystem of a
<glossterm linkend="glossary-server">server</glossterm> that contains all
- data files and subdirectories associated with an
- <glossterm linkend="glossary-instance">instance</glossterm> (with the
- exception of <glossterm linkend="glossary-tablespace">tablespaces</glossterm>).
+ 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>).
The environment variable <literal>PGDATA</literal> is commonly used to
- refer to the
- <glossterm linkend="glossary-data-directory">data directory</glossterm>.
+ refer to the data directory.
</para>
<para>
- An <glossterm linkend="glossary-instance">instance</glossterm>'s storage
+ A <glossterm linkend="glossary-instance">cluster</glossterm>'s storage
space comprises the data directory plus any additional tablespaces.
</para>
<para>
@@ -418,7 +418,7 @@
<glossdef>
<para>
A named collection of
- <glossterm linkend="glossary-sql-object">SQL objects</glossterm>.
+ <glossterm linkend="glossary-sql-object">local SQL objects</glossterm>.
</para>
<para>
For more information, see
@@ -427,6 +427,22 @@
</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 meta-data.
+ Sometimes referred to as a
+ <firstterm>cluster</firstterm>.
+ </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>
+ </glossentry>
+
<glossentry>
<glossterm>Database server</glossterm>
<glosssee otherterm="glossary-instance" />
@@ -634,7 +650,7 @@
<glossterm>Function</glossterm>
<glossdef>
<para>
- Any defined transformation of data. Many functions are already defined
+ A defined transformation of data. Many functions are already defined
within <productname>PostgreSQL</productname> itself, but user-defined
ones can also be added.
</para>
@@ -724,14 +740,12 @@
<glossterm>Instance</glossterm>
<glossdef>
<para>
- A set of databases and accompanying global SQL objects that are stored in
- the same <glossterm linkend="glossary-data-directory">data directory</glossterm>
- in a single <glossterm linkend="glossary-server">server</glossterm>.
- If running, one
+ A group of backend and auxiliary processes that communicate using
+ a common shared memory area. One
<glossterm linkend="glossary-postmaster">postmaster process</glossterm>
- manages a group of backend and auxiliary processes that communicate
- using a common <glossterm linkend="glossary-shared-memory">shared memory</glossterm>
- area. Many instances can run on the same
+ 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>
@@ -739,14 +753,10 @@
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 client processes,
+ <glossterm linkend="glossary-connection">connections</glossterm> to
+ <glossterm linkend="glossary-client">client processes</glossterm>,
privilege verification, crash recovery, replication, etc.
</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>
</glossdef>
</glossentry>
@@ -1245,12 +1255,17 @@
<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.
+ Each SQL object must reside in exactly one schema
+ (though certain types of SQL objects exist outside schemas).
</para>
<para>
The names of SQL objects of the same type in the same schema are enforced
to be unique.
There is no restriction on reusing a name in multiple schemas.
+ For local objects that exist outside schemas, their names are enforced
+ unique across the whole database. For global objects, their names
+ are enforced unique across the whole
+ <glossterm linkend="glossary-db-cluster">database cluster</glossterm>.
</para>
<para>
All system-defined SQL objects reside in schema <literal>pg_catalog</literal>,
@@ -1384,27 +1399,34 @@
</glossentry>
<glossentry id="glossary-sql-object">
- <glossterm>SQL Object</glossterm>
+ <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>.
- <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>.
</para>
<para>
Most local objects belong to a specific
- <glossterm linkend="glossary-schema">schema</glossterm> in their containing database.
+ <glossterm linkend="glossary-schema">schema</glossterm> in their
+ containing database, such as
+ <glossterm linkend="glossary-relation">all types of relations</glossterm>,
+ <glossterm linkend="glossary-function">all types of functions</glossterm>,
+ data types, etc.
There also exist local objects that do not belong to 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>.
- </para>
+ </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>.
+ </para>
<para>
For more information, see
<xref linkend="manage-ag-overview"/>.
@@ -1489,7 +1511,7 @@
which require storage beyond their definition in the
<glossterm linkend="glossary-system-catalog">system catalog</glossterm>
must belong to a single tablespace.
- Initially, an instance contains a single usable tablespace which is
+ Initially, a database cluster contains a single usable tablespace which is
used as the default one for all SQL objects, called <literal>pg_default</literal>.
</para>
<para>
On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote:
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml index 25b03f3b37..e29b55e5ac 100644 --- a/doc/src/sgml/glossary.sgml +++ b/doc/src/sgml/glossary.sgml @@ -395,15 +395,15 @@ <para> The base directory on the filesystem of a <glossterm linkend="glossary-server">server</glossterm> that contains all - data files and subdirectories associated with an - <glossterm linkend="glossary-instance">instance</glossterm> (with the - exception of <glossterm linkend="glossary-tablespace">tablespaces</glossterm>). + 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) WAL
+ <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 meta-data.
metadata
@@ -1245,12 +1255,17 @@ <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. + Each SQL object must reside in exactly one schema + (though certain types of SQL objects exist outside schemas).
(except for global objects which ..)
<para> The names of SQL objects of the same type in the same schema are enforced to be unique. There is no restriction on reusing a name in multiple schemas. + For local objects that exist outside schemas, their names are enforced + unique across the whole database. For global objects, their names
I would say "unique within the database"
+ are enforced unique across the whole + <glossterm linkend="glossary-db-cluster">database cluster</glossterm>.
and "unique within the whole db cluster"
Most local objects belong to a specific - <glossterm linkend="glossary-schema">schema</glossterm> in their containing database. + <glossterm linkend="glossary-schema">schema</glossterm> in their + containing database, such as + <glossterm linkend="glossary-relation">all types of relations</glossterm>, + <glossterm linkend="glossary-function">all types of functions</glossterm>,
Maybe say: >Relations< (all types), and >Functions< (all types)
used as the default one for all SQL objects, called <literal>pg_default</literal>.
"the default" (remove "one")
--
Justin
On 17.06.20 02:09, Alvaro Herrera wrote:
On 2020-Jun-09, J�rgen Purtz wrote:
Can you agree to the following definitions? If no, we can alternatively
formulate for each of them: "Under discussion - currently not defined". My
proposals are inspired by chapter 2.2 Concepts: "Tables are grouped into
databases, and a collection of databases managed by a single PostgreSQL
server instance constitutes a database cluster."After sleeping on it a few more times, I don't oppose the idea of making
"instance" be the running state and "database cluster" the on-disk stuff
that supports the instance. Here's a patch that does things pretty much
along the lines you suggested.I made small adjustments to "SQL objects":
* SQL objects in schemas were said to have their names unique in the
schema, but we failed to say anything about names of objects not in
schemas and global objects. Added that.* Had example object types for global objects and objects not in
schemas, but no examples for objects in schemas. Added that.Some programs whose output we could tweak per this:
pg_ctlpg_ctl is a utility to initialize, start, stop, or control a PostgreSQL server.
-D, --pgdata=DATADIR location of the database storage areato:
pg_ctl is a utility to initialize or control a PostgreSQL database cluster.
-D, --pgdata=DATADIR location of the database directorypg_basebackup:
pg_basebackup takes a base backup of a running PostgreSQL server.
to:
pg_basebackup takes a base backup of a PostgreSQL instance.
+1, with two formal changes:
-� Rearrangement of term "Data page" to meet alphabetical order.
-� Add </glossdef> in one case to meet xml-well-formedness.
One last question: The definition of "Data directory" reads "... A
cluster's storage space comprises the data directory plus ..." and
'cluster' links to '"glossary-instance". Shouldn't it link to
"glossary-db-cluster"?
--
J�rgen Purtz
Attachments:
0004-glossary.patchtext/x-patch; charset=UTF-8; name=0004-glossary.patchDownload
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index e29b55e5ac..0499f9044f 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -413,6 +413,22 @@
</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-database">
<glossterm>Database</glossterm>
<glossdef>
@@ -441,6 +457,7 @@
<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>
+ </glossdef>
</glossentry>
<glossentry>
@@ -448,22 +465,6 @@
<glosssee otherterm="glossary-instance" />
</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>
On 2020-Jun-16, Justin Pryzby wrote:
On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote:
Thanks for the review. I merged all your suggestions. This one:
Most local objects belong to a specific + <glossterm linkend="glossary-schema">schema</glossterm> in their + containing database, such as + <glossterm linkend="glossary-relation">all types of relations</glossterm>, + <glossterm linkend="glossary-function">all types of functions</glossterm>,Maybe say: >Relations< (all types), and >Functions< (all types)
led me down not one but two rabbit holes; first I realized that
"functions" is an insufficient term since procedures should also be
included but weren't, so I had to add the more generic term "routine"
and then modify the definitions of all routine types to mix in well. I
think overall the quality of these definitions is improved as a result.
I also felt the need to revise the definition of "relations", so I did
that too; this made me change the definition of resultset too.
On 2020-Jun-17, J�rgen Purtz wrote:
+1, with two formal changes:
-� Rearrangement of term "Data page" to meet alphabetical order.
To forestall these ordering issues (look, another rabbit hole), I
grepped the file for all glossterms and sorted that under en_US rules,
then reordered the terms to match that. Turns out there were several
other ordering mistakes.
git grep '<glossterm>' | sed -e 's/<[^>]*>\([^<]*\)<[^>]*>/\1/' > orig
LC_COLLATE=en_US.UTF-8 sort orig > sorted
(Eliminating the tags is important, otherwise the sort uses the tags
themselves to disambiguate)
One last question: The definition of "Data directory" reads "... A cluster's
storage space comprises the data directory plus ..." and 'cluster' links to
'"glossary-instance". Shouldn't it link to "glossary-db-cluster"?
Yes, an oversight, thanks.
I also added TPS, because I had already written it.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
glossary-2.patchtext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 25b03f3b37..5274feabba 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -23,7 +23,7 @@
</glossentry>
<glossentry id="glossary-aggregate">
- <glossterm>Aggregate function</glossterm>
+ <glossterm>Aggregate function (routine)</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-function">function</glossterm> that
@@ -39,6 +39,11 @@
</glossdef>
</glossentry>
+ <glossentry>
+ <glossterm>Analytic function</glossterm>
+ <glosssee otherterm="glossary-window-function" />
+ </glossentry>
+
<glossentry id="glossary-analyze">
<glossterm>Analyze (operation)</glossterm>
<glossdef>
@@ -57,11 +62,6 @@
</glossdef>
</glossentry>
- <glossentry>
- <glossterm>Analytic function</glossterm>
- <glosssee otherterm="glossary-window-function" />
- </glossentry>
-
<glossentry id="glossary-atomic">
<glossterm>Atomic</glossterm>
<glossdef>
@@ -389,40 +389,33 @@
<glosssee otherterm="glossary-data-directory" />
</glossentry>
- <glossentry id="glossary-data-directory">
- <glossterm>Data directory</glossterm>
+ <glossentry id="glossary-database">
+ <glossterm>Database</glossterm>
<glossdef>
<para>
- The base directory on the filesystem of a
- <glossterm linkend="glossary-server">server</glossterm> that contains all
- data files and subdirectories associated with an
- <glossterm linkend="glossary-instance">instance</glossterm> (with the
- exception of <glossterm linkend="glossary-tablespace">tablespaces</glossterm>).
- The environment variable <literal>PGDATA</literal> is commonly used to
- refer to the
- <glossterm linkend="glossary-data-directory">data directory</glossterm>.
- </para>
- <para>
- An <glossterm linkend="glossary-instance">instance</glossterm>'s storage
- space comprises the data directory plus any additional tablespaces.
+ A named collection of
+ <glossterm linkend="glossary-sql-object">local SQL objects</glossterm>.
</para>
<para>
For more information, see
- <xref linkend="storage-file-layout"/>.
+ <xref linkend="manage-ag-overview"/>.
</para>
</glossdef>
</glossentry>
- <glossentry id="glossary-database">
- <glossterm>Database</glossterm>
+ <glossentry id="glossary-db-cluster">
+ <glossterm>Database cluster</glossterm>
<glossdef>
<para>
- A named collection of
- <glossterm linkend="glossary-sql-object">SQL objects</glossterm>.
+ A collection of databases and global SQL objects,
+ and their common static and dynamic metadata.
+ Sometimes referred to as a
+ <firstterm>cluster</firstterm>.
</para>
<para>
- For more information, see
- <xref linkend="manage-ag-overview"/>.
+ 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>
</glossdef>
</glossentry>
@@ -432,6 +425,31 @@
<glosssee otherterm="glossary-instance" />
</glossentry>
+ <glossentry id="glossary-data-directory">
+ <glossterm>Data directory</glossterm>
+ <glossdef>
+ <para>
+ The base directory on the filesystem 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>
@@ -578,7 +596,7 @@
</glossentry>
<glossentry id="glossary-foreign-table">
- <glossterm>Foreign table</glossterm>
+ <glossterm>Foreign table (relation)</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> which appears to have
@@ -631,12 +649,20 @@
</glossentry>
<glossentry id="glossary-function">
- <glossterm>Function</glossterm>
+ <glossterm>Function (routine)</glossterm>
<glossdef>
<para>
- Any defined transformation of data. Many functions are already defined
- within <productname>PostgreSQL</productname> itself, but user-defined
- ones can also be added.
+ 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
@@ -689,13 +715,12 @@
</glossentry>
<glossentry id="glossary-index">
- <glossterm>Index</glossterm>
+ <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-relation">relation</glossterm> types
- such as a <glossterm linkend="glossary-materialized-view">materialized view</glossterm>).
+ or <glossterm linkend="glossary-materialized-view">materialized view</glossterm>.
Its internal structure supports fast retrieval of and access to the original
data.
</para>
@@ -724,14 +749,12 @@
<glossterm>Instance</glossterm>
<glossdef>
<para>
- A set of databases and accompanying global SQL objects that are stored in
- the same <glossterm linkend="glossary-data-directory">data directory</glossterm>
- in a single <glossterm linkend="glossary-server">server</glossterm>.
- If running, one
+ A group of backend and auxiliary processes that communicate using
+ a common shared memory area. One
<glossterm linkend="glossary-postmaster">postmaster process</glossterm>
- manages a group of backend and auxiliary processes that communicate
- using a common <glossterm linkend="glossary-shared-memory">shared memory</glossterm>
- area. Many instances can run on the same
+ 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>
@@ -739,14 +762,10 @@
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 client processes,
+ <glossterm linkend="glossary-connection">connections</glossterm> to
+ <glossterm linkend="glossary-client">client processes</glossterm>,
privilege verification, crash recovery, replication, etc.
</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>
</glossdef>
</glossentry>
@@ -769,8 +788,10 @@
<glossterm>Join</glossterm>
<glossdef>
<para>
- An <acronym>SQL</acronym> keyword used in <command>SELECT</command> statements for
- combining data from multiple <glossterm linkend="glossary-relation">relations</glossterm>.
+ 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>
@@ -781,10 +802,10 @@
<para>
A means of identifying a <glossterm linkend="glossary-tuple">row</glossterm> within a
<glossterm linkend="glossary-table">table</glossterm> or
- <glossterm linkend="glossary-relation">relation</glossterm> by
+ other <glossterm linkend="glossary-relation">relation</glossterm> by
values contained within one or more
<glossterm linkend="glossary-attribute">attributes</glossterm>
- in that table.
+ in that relation.
</para>
</glossdef>
</glossentry>
@@ -813,15 +834,6 @@
</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-logged">
<glossterm>Logged</glossterm>
<glossdef>
@@ -855,6 +867,15 @@
</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>
<glossterm>Master (server)</glossterm>
<glosssee otherterm="glossary-primary-server" />
@@ -883,12 +904,13 @@
</glossentry>
<glossentry id="glossary-materialized-view">
- <glossterm>Materialized view</glossterm>
+ <glossterm>Materialized view (relation)</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
- defined in the same way that a <glossterm linkend="glossary-view">view</glossterm>
- is, but stores data in the same way that a
+ 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>, or
<command>DELETE</command> operations.
@@ -949,6 +971,8 @@
<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>:
@@ -961,16 +985,18 @@
</glossdef>
<glossdef>
<para>
- In reference to a <glossterm linkend="glossary-window-function">window function</glossterm>:
+ 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> can be considered by the
- function.
+ <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</glossterm>
+ <glossterm>Partitioned table (relation)</glossterm>
<glossdef>
<para>
A <glossterm linkend="glossary-relation">relation</glossterm> that is
@@ -997,20 +1023,6 @@
</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-primary-key">
<glossterm>Primary key</glossterm>
<glossdef>
@@ -1031,19 +1043,29 @@
</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</glossterm>
+ <glossterm>Procedure (routine)</glossterm>
<glossdef>
<para>
- A defined set of instructions for manipulating data within a
- <glossterm linkend="glossary-database">database</glossterm>.
- A <glossterm linkend="glossary-procedure">procedure</glossterm> can
- be written in a variety of programming languages. They are
- similar to <glossterm linkend="glossary-function">functions</glossterm>,
- but are different in that they must be invoked via the <command>CALL</command>
- command rather than the <command>SELECT</command> or <command>PERFORM</command>
- commands, and they are allowed to make transactional statements such
+ 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
@@ -1115,6 +1137,11 @@
<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>
@@ -1155,16 +1182,23 @@
<glossterm>Result set</glossterm>
<glossdef>
<para>
- A data structure 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
+ 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>, or
<command>DELETE</command> command if the <literal>RETURNING</literal>
- clause is specified. The data structure consists of zero or more
- <glossterm linkend="glossary-tuple">rows</glossterm> with the same ordered set of
- <glossterm linkend="glossary-attribute">attributes</glossterm>.
+ 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>
@@ -1216,6 +1250,27 @@
</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">aggregates 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" />
@@ -1248,16 +1303,7 @@
Each SQL object must reside in exactly one schema.
</para>
<para>
- The names of SQL objects of the same type in the same schema are enforced
- to be unique.
- There is no restriction on reusing a name in multiple schemas.
- </para>
- <para>
- All system-defined SQL objects reside in schema <literal>pg_catalog</literal>,
- and commonly many user-defined SQL objects reside in the default schema
- <literal>public</literal>,
- but it is common and recommended that other schemas are created to hold
- application-specific SQL objects.
+ All system-defined SQL objects reside in schema <literal>pg_catalog</literal>.
</para>
</glossdef>
<glossdef>
@@ -1299,6 +1345,19 @@
</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>
@@ -1339,19 +1398,6 @@
</glossdef>
</glossentry>
- <glossentry id="glossary-sequence">
- <glossterm>Sequence</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>
-
<glossentry id="glossary-shared-memory">
<glossterm>Shared memory</glossterm>
<glossdef>
@@ -1378,33 +1424,43 @@
</glossdef>
</glossentry>
- <glossentry>
- <glossterm>Standby (server)</glossterm>
- <glosssee otherterm="glossary-replica" />
- </glossentry>
-
<glossentry id="glossary-sql-object">
- <glossterm>SQL Object</glossterm>
+ <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>.
- <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>.
</para>
<para>
Most local objects belong to a specific
- <glossterm linkend="glossary-schema">schema</glossterm> in their containing database.
+ <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 name of such objects of the same type in the same schema
+ are enforced unique.
+ </para>
+ <para>
There also exist local objects that do not belong to 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>.
- </para>
+ The name of such objects of the same type are enforced 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 unique within the whole
+ database cluster.
+ </para>
<para>
For more information, see
<xref linkend="manage-ag-overview"/>.
@@ -1421,6 +1477,11 @@
</glossdef>
</glossentry>
+ <glossentry>
+ <glossterm>Standby (server)</glossterm>
+ <glosssee otherterm="glossary-replica" />
+ </glossentry>
+
<glossentry id="glossary-stats-collector">
<glossterm>Stats collector</glossterm>
<glossdef>
@@ -1489,8 +1550,8 @@
which require storage beyond their definition in the
<glossterm linkend="glossary-system-catalog">system catalog</glossterm>
must belong to a single tablespace.
- Initially, an instance contains a single usable tablespace which is
- used as the default one for all SQL objects, called <literal>pg_default</literal>.
+ 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
@@ -1577,6 +1638,18 @@
</glossdef>
</glossentry>
+ <glossentry id="glossary-tps">
+ <glossterm>Transactions per second (TPS)</glossterm>
+ <glossdef>
+ <para>
+ Average number of transactions that are executed per second,
+ totalled 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>
@@ -1818,28 +1891,32 @@
</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>
+ <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</glossterm>
+ <glossterm>Window function (routine)</glossterm>
<glossdef>
<para>
- A type of <glossterm linkend="glossary-function">function</glossterm> whose
- result is based on values found in
- <glossterm linkend="glossary-tuple">rows</glossterm> of the same
- <glossterm linkend="glossary-partition">partition</glossterm>.
+ 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.
@@ -1857,8 +1934,8 @@
<glossdef>
<para>
The journal that keeps track of the changes in the
- <glossterm linkend="glossary-instance">instance</glossterm> as user- and
- system-invoked operations take place.
+ <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>.
Import Notes
Reply to msg id not found: 292d6f42-e31c-bc73-6cfb-9083bc2c07fc@purtz.de20200617003349.GN20404@telsasoft.com | Resolved by subject fallback
On 2020-06-19 01:51, Alvaro Herrera wrote:
On 2020-Jun-16, Justin Pryzby wrote:
On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote:
I noticed one typo:
'aggregates functions' should be
'aggregate functions'
And one thing that I am not sure of (but strikes me as a bit odd):
there are several cases of
'are enforced unique'. Should that not be
'are enforced to be unique' ?
Anther small mistake (2x):
'The name of such objects of the same type are' should be
'The names of such objects of the same type are'
(this phrase occurs 2x wrong, 1x correct)
thanks,
Erik Rijkers
Thanks for these fixes! I included all of these.
On 2020-Jun-19, Erik Rijkers wrote:
And one thing that I am not sure of (but strikes me as a bit odd):
there are several cases of
'are enforced unique'. Should that not be
'are enforced to be unique' ?
I included this change too; I am not too sure of it myself. If some
English language neatnik wants to argue one way or the other, be my
guest.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 19.06.20 19:10, Alvaro Herrera wrote:
Thanks for these fixes! I included all of these.
On 2020-Jun-19, Erik Rijkers wrote:
And one thing that I am not sure of (but strikes me as a bit odd):
there are several cases of
'are enforced unique'. Should that not be
'are enforced to be unique' ?I included this change too; I am not too sure of it myself. If some
English language neatnik wants to argue one way or the other, be my
guest.
- Added '(process)' to the two terms 'Autovacuum' and 'Stats Collector'
- Removed link to himself in 'Logger (process)'
- new term: Base Backup
--
Jürgen Purtz
Attachments:
0005-glossary.patchtext/x-patch; charset=UTF-8; name=0005-glossary.patchDownload
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 76525c6302..58e5071642 100644
--- a/doc/src/sgml/glossary.sgml
+++ b/doc/src/sgml/glossary.sgml
@@ -108,7 +108,7 @@
</glossentry>
<glossentry id="glossary-autovacuum">
- <glossterm>Autovacuum</glossterm>
+ <glossterm>Autovacuum (process)</glossterm>
<glossdef>
<para>
A set of background processes that routinely perform
@@ -178,6 +178,19 @@
</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>
@@ -855,8 +868,7 @@
<glossterm>Logger (process)</glossterm>
<glossdef>
<para>
- If activated, the
- <glossterm linkend="glossary-logger">Logger</glossterm> process
+ If activated, the process
writes information about database events into the current
<glossterm linkend="glossary-log-file">log file</glossterm>.
When reaching certain time- or
@@ -1486,7 +1498,7 @@
</glossentry>
<glossentry id="glossary-stats-collector">
- <glossterm>Stats collector</glossterm>
+ <glossterm>Stats collector (process)</glossterm>
<glossdef>
<para>
This process collects statistical information about the
On 2020-Jul-21, J�rgen Purtz wrote:
- Added '(process)' to the two terms 'Autovacuum' and 'Stats Collector'
- Removed link to himself in 'Logger (process)'
- new term: Base Backup
Pushed. I was not courageous enough to include "base backup" in 13, so
that one's in master only, but the other ones are in both branches.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services