+ Also there are some predefined conversions. See
linkend="conversion-names"> for available conversions.
convert('text_in_utf8', 'UTF8', 'LATIN1')
Notice that except for the two-argument form of enum_range>,
these functions disregard the specific value passed to them; they care
- only about its declared datatype. Either NULL or a specific value of
+ only about its declared data type. Either null or a specific value of
the type can be passed, with the same result. It is more common to
apply these functions to a table column or function argument than to
a hardwired type name as suggested by the examples.
...
]]>
- If no table name is avaible, that is, when mapping a query or a
+ If no table name is available, that is, when mapping a query or a
cursor, the string table is used in the first
format, row in the second format.
-
+
High Availability, Load Balancing, and Replication
Performance must be considered in any choice. There is usually a
- tradeoff between functionality and
+ trade-off between functionality and
performance. For example, a full synchronous solution over a slow
network might cut performance by more than half, while an asynchronous
one might have a minimal performance impact.
- Asynchronous Multi-Master Replication
+ Asynchronous Multimaster Replication
For servers that are not regularly connected, like laptops or
remote servers, keeping data consistent among servers is a
- challenge. Using asynchronous multi-master replication, each
+ challenge. Using asynchronous multimaster replication, each
server works independently, and periodically communicates with
the other servers to identify conflicting transactions. The
conflicts can be resolved by users or conflict resolution rules.
- Synchronous Multi-Master Replication
+ Synchronous Multimaster Replication
- In synchronous multi-master replication, each server can accept
+ In synchronous multimaster replication, each server can accept
write requests, and modified data is transmitted from the
original server to every other server before each transaction
commits. Heavy write activity can cause excessive locking,
leading to poor performance. In fact, write performance is
often worse than that of a single server. Read requests can
be sent to any server. Some implementations use shared disk
- to reduce the communication overhead. Synchronous multi-master
+ to reduce the communication overhead. Synchronous multimaster
replication is best for mostly read workloads, though its big
advantage is that any server can accept write requests —
there is no need to partition workloads between master and
Warm Standby Using PITR
Master-Slave Replication
Statement-Based Replication Middleware
- Asynchronous Multi-Master Replication
- Synchronous Multi-Master Replication
+ Asynchronous Multimaster Replication
+ Synchronous Multimaster Replication
- Multi-Server Parallel Query Execution
+ Multiple-Server Parallel Query Execution
-
+
ActiveState Perl is required to run the build generation scripts. MinGW
- or Cygwin perl will not work. It must also be present in the PATH.
+ or Cygwin Perl will not work. It must also be present in the PATH.
Binaries can be downloaded from
To change the default build configuration to debug, put the following
- in the buildenv.bat file:
+ in the buildenv.bat file:
set CONFIG=Debug
To run the regression tests, make sure you have completed the build of all
required parts first. Also, make sure that the DLLs required to load all
- parts of the system (such as the perl and python DLLs for the procedural
- languages) are present in the system PATH. If they are not, set it through
+ parts of the system (such as the Perl and Python DLLs for the procedural
+ languages) are present in the system path. If they are not, set it through
the buildenv.bat file. To run the tests, run one of
the following commands from the src\tools\msvc
directory:
To change the schedule used (default is the parallel), append it to the
- commandline like:
+ command line like:
vcregress check serial
- DocBook DSSL 1.79
+ DocBook DSSSL 1.79
Download from
-
+
PostgreSQL>]]>
TCLSH
- Full path to the Tcl interpreter. This wil be used to
+ Full path to the Tcl interpreter. This will be used to
determine the dependencies for building PL/Tcl.
-
+
used. (Therefore, put more-specific entries first when you are using
wildcards.) If an entry needs to contain : or
\, escape this character with \.
- A host name of localhost> matches both TCP (hostname
+ A host name of localhost> matches both TCP (host name
localhost>) and Unix domain socket (pghost> empty
or the default socket directory) connections coming from the local
machine.
-
+
Routine Database Maintenance Tasks
UPDATE> or DELETE> of a row does not
immediately remove the old version of the row.
This approach is necessary to gain the benefits of multiversion
- concurrency control (see ): the row version
+ concurrency control (see ): the row versions
must not be deleted while it is still potentially visible to other
transactions. But eventually, an outdated or deleted row version is no
longer of interest to any transaction. The space it occupies must be
Beginning in
PostgreSQL 8.3, autovacuum has a
- multi-process architecture: there is a daemon process, called the
+ multiprocess architecture: There is a daemon process, called the
autovacuum launcher, which is in charge of starting
an autovacuum worker process on each database every
seconds. On each run, the worker
-
+
Monitoring Database Activity
One row only, showing cluster-wide statistics from the
background writer: number of scheduled checkpoints, requested
checkpoints, buffers written by checkpoints and cleaning scans,
- and the number of times the bgwriter stopped a cleaning scan
+ and the number of times the background writer stopped a cleaning scan
because it had written too many buffers. Also includes
statistics about the shared buffer pool, including buffers written
by backends (that is, not by the background writer) and total buffers
pg_stat_get_bgwriter_timed_checkpoints()
bigint
- The number of times the bgwriter has started timed checkpoints
+ The number of times the background writer has started timed checkpoints
(because the checkpoint_timeout time has expired)
pg_stat_get_bgwriter_requested_checkpoints()
bigint
- The number of times the bgwriter has started checkpoints based
+ The number of times the background writer has started checkpoints based
on requests from backends because the checkpoint_segments
has been exceeded or because the CHECKPOINT
command has been issued
pg_stat_get_bgwriter_buf_written_checkpoints()
bigint
- The number of buffers written by the bgwriter during checkpoints
+ The number of buffers written by the background writer during checkpoints
pg_stat_get_bgwriter_buf_written_clean()
bigint
- The number of buffers written by the bgwriter for routine cleaning of
+ The number of buffers written by the background writer for routine cleaning of
dirty pages
pg_stat_get_bgwriter_maxwritten_clean()
bigint
- The number of times the bgwriter has stopped its cleaning scan because
+ The number of times the background writer has stopped its cleaning scan because
it has written more buffers than specified in the
bgwriter_lru_maxpages parameter
You should take care that the data types specified for the probe arguments
- match the datatypes of the variables used in the PG_TRACE>
+ match the data types of the variables used in the PG_TRACE>
macro. This is not checked at compile time. You can check that your newly
added trace point is available by recompiling, then running the new binary,
and as root, executing a DTrace command such as:
-
+
Performance Tips
and
linkend="guc-join-collapse-limit">
are similarly named because they do almost the same thing: one controls
- when the planner will flatten out> subselects, and the
+ when the planner will flatten out> subqueries, and the
other controls when it will flatten out explicit joins. Typically
you would either set join_collapse_limit> equal to
- from_collapse_limit> (so that explicit joins and subselects
+ from_collapse_limit> (so that explicit joins and subqueries
act similarly) or set join_collapse_limit> to 1 (if you want
to control join order with explicit joins). But you might set them
differently if you are trying to fine-tune the trade-off between planning
-
+
PL/pgSQL - SQL Procedural Language
where
search_term> is a PL/pgSQL
variable. The cached plan for this query will never use an index on
word>, since the planner cannot assume that the
- LIKE> pattern will be left-anchored at runtime. To use
+ LIKE> pattern will be left-anchored at run time. To use
an index the query must be planned with a specific constant
LIKE> pattern provided. This is another situation where
EXECUTE can be used to force a new plan to be
of course the integrity of the constraint cannot be guaranteed if the
triggers are not executed.
The trigger firing mechanism is also affected by the configuration
- variable . Simply ENABLEd
+ variable . Simply enabled
triggers will fire when the replication role is origin>
(the default) or local>. Triggers configured ENABLE REPLICA
will only fire if the session is in replica> mode and triggers
The obsolete options SORT1>, SORT2>,
LTCMP>, and GTCMP> were formerly used to
- specify the names of sort operators associated with a mergejoinable
+ specify the names of sort operators associated with a merge-joinable
operator. This is no longer necessary, since information about
- associated operators is found by looking at btree operator families
+ associated operators is found by looking at B-tree operator families
instead. If one of these options is given, it is ignored except
for implicitly setting MERGES> true.
from this cursor. The cursor must be a simple (non-join, non-aggregate)
query on the DELETE>'s target table.
Note that WHERE CURRENT OF> cannot be
- specified together with a boolean condition.
+ specified together with a Boolean condition.
- In order to measure the runtime cost of each node in the execution
+ In order to measure the run-time cost of each node in the execution
plan, the current implementation of EXPLAIN
ANALYZE can add considerable profiling overhead to query
execution. As a result, running EXPLAIN ANALYZE
assumed by default. Alternatively, a specific ordering operator
name can be specified in the USING> clause.
An ordering operator must be a less-than or greater-than
- member of some btree operator family.
+ member of some B-tree operator family.
ASC> is usually equivalent to USING <> and
DESC> is usually equivalent to USING >>.
(But the creator of a user-defined data type can define exactly what the
from this cursor. The cursor must be a simple (non-join, non-aggregate)
query on the UPDATE>'s target table.
Note that WHERE CURRENT OF> cannot be
- specified together with a boolean condition.
+ specified together with a Boolean condition.
-
+
Operating System Environment
NFS> implementations have non-standard semantics, this can
cause reliability problems (see
url="http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html">).
- Specifically, delayed (asynchonous) writes to the
NFS>
+ Specifically, delayed (asynch
ronous) writes to the
NFS>
server can cause reliability problems; if possible, mount
-
NFS> file systems synchonously (without caching) to avoid
+
NFS> file systems synchronously (without caching) to avoid
this. (Storage Area Networks (
SAN>) use a low-level
communication protocol rather than
NFS>.)
-
+
Full Text Search
Textual search operators have existed in databases for years.
~, ~*, LIKE, and
- ILIKE operators for textual datatypes, but they lack
+ ILIKE operators for textual data types, but they lack
many essential properties required by modern information systems:
- Map synonyms to a single word using
ispell>.
+ Map synonyms to a single word using
Ispell>.
Map different variations of a word to a canonical form using
to_tsquery creates a tsquery> value from
querytext, which must consist of single tokens
- separated by the boolean operators & (AND),
+ separated by the Boolean operators & (AND),
| (OR) and ! (NOT). These operators
can be grouped using parentheses. In other words, the input to
to_tsquery must already follow the general rules for
plainto_tsquery> transforms unformatted text
querytext to tsquery.
The text is parsed and normalized much as for to_tsvector>,
- then the & (AND) boolean operator is inserted
+ then the & (AND) Boolean operator is inserted
between surviving words.
Note that plainto_tsquery> cannot
- recognize either boolean operators or weight labels in its input:
+ recognize either Boolean operators or weight labels in its input:
SELECT plainto_tsquery('english', 'The Fat & Rats:C');
- HighlightAll: boolean flag; if
+ HighlightAll: Boolean flag; if
true the whole document will be highlighted.
tsvector summary, so it can be slow and should be used with
care. A typical mistake is to call ts_headline for
every matching document when only ten documents are
- to be shown.
SQL sub
selects can help; here is an
+ to be shown.
SQL sub
queries can help; here is an
example:
- Linguistic - ispell dictionaries try to reduce input words to a
+ Linguistic - Ispell dictionaries try to reduce input words to a
normalized form; stemmer dictionaries remove word endings
Below we create a dictionary and bind some token types to
- an astronomical thesaurus and english stemmer:
+ an astronomical thesaurus and English stemmer:
CREATE TEXT SEARCH DICTIONARY thesaurus_astro (
Several predefined text search configurations are available, and
you can create custom configurations easily. To facilitate management
of text search objects, a set of
SQL commands
- is available, and there are several psql commands that display information
+ is available, and there are several
psql commands that display information
about text search objects ().
);
- Next we register the
ispell> dictionary
+ Next we register the
Ispell> dictionary
english_ispell, which has its own configuration files:
For a more extensive demonstration, we
first create a public.english configuration and
- ispell dictionary for the English language:
+ Ispell dictionary for the English language:
-
+
Reliability and the Write-Ahead Log
Asynchronous commit> is an option that allows transactions
to complete more quickly, at the cost that the most recent transactions may
be lost if the database should crash. In many applications this is an
- acceptable tradeoff.
+ acceptable trade-off.
The user can select the commit mode of each transaction, so that
it is possible to have both synchronous and asynchronous commit
- transactions running concurrently. This allows flexible tradeoffs
+ transactions running concurrently. This allows flexible trade-offs
between performance and certainty of transaction durability.
The commit mode is controlled by the user-settable parameter
, which can be changed in any of
Certain utility commands, for instance DROP TABLE>, are
forced to commit synchronously regardless of the setting of
synchronous_commit. This is to ensure consistency
- between the server's filesystem and the logical state of the database.
+ between the server's file system and the logical state of the database.
The commands supporting two-phase commit, such as PREPARE
TRANSACTION>, are also always synchronous.
then changes made during that transaction will> be lost.
The duration of the
- risk window is limited because a background process (the wal
+ risk window is limited because a background process (the WAL
writer>) flushes unwritten
WAL records to disk
every milliseconds.
The actual maximum duration of the risk window is three times
- wal_writer_delay because the wal writer is
+ wal_writer_delay because the WAL writer is
designed to favor writing whole pages at a time during busy periods.
-
+
User-Defined Operators
some form of equality. In most cases it is only practical to support
hashing for operators that take the same data type on both sides.
However, sometimes it is possible to design compatible hash functions
- for two or more datatypes; that is, functions that will generate the
+ for two or more data types; that is, functions that will generate the
same hash codes for equal> values, even though the values
have different representations. For example, it's fairly simple
to arrange this property when hashing integers of different widths.
if they are different) that appears in the same operator family.
If this is not the case, planner errors might occur when the operator
is used. Also, it is a good idea (but not strictly required) for
- a hash operator family that supports multiple datatypes to provide
- equality operators for every combination of the datatypes; this
+ a hash operator family that supports multiple data types to provide
+ equality operators for every combination of the data types; this
allows better optimization.
if they are different) that appears in the same operator family.
If this is not the case, planner errors might occur when the operator
is used. Also, it is a good idea (but not strictly required) for
- a btree operator family that supports multiple datatypes to provide
- equality operators for every combination of the datatypes; this
+ a btree operator family that supports multiple data types to provide
+ equality operators for every combination of the data types; this
allows better optimization.