diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
index ade0ad97d8e..e56a13283fa 100644
--- a/doc/src/sgml/arch-dev.sgml
+++ b/doc/src/sgml/arch-dev.sgml
@@ -7,7 +7,7 @@
Author
This chapter originated as part of
- , Stefan Simkovics'
+ Stefan Simkovics'
Master's Thesis prepared at Vienna University of Technology under the direction
of O.Univ.Prof.Dr. Georg Gottlob and Univ.Ass. Mag. Katrin Seyr.
@@ -17,10 +17,7 @@
This chapter gives an overview of the internal structure of the
backend of PostgreSQL. After having
read the following sections you should have an idea of how a query
- is processed. This chapter does not aim to provide a detailed
- description of the internal operation of
- PostgreSQL, as such a document would be
- very extensive. Rather, this chapter is intended to help the reader
+ is processed. This chapter is intended to help the reader
understand the general sequence of operations that occur within the
backend from the point at which a query is received, to the point
at which the results are returned to the client.
@@ -30,8 +27,8 @@
The Path of a Query
- Here we give a short overview of the stages a query has to pass in
- order to obtain a result.
+ Here we give a short overview of the stages a query has to pass
+ to obtain a result.
@@ -125,10 +122,10 @@
use a supervisor process (also
master process) that spawns a new
server process every time a connection is requested. This supervisor
- process is called postgres and listens at a
+ process is called postmaster and listens at a
specified TCP/IP port for incoming connections. Whenever a request
- for a connection is detected the postgres
- process spawns a new server process. The server tasks
+ for a connection is detected the postmaster
+ process spawns a new server process. The server processes
communicate with each other using semaphores and
shared memory to ensure data integrity
throughout concurrent data access.
@@ -230,7 +227,7 @@
A detailed description of bison or
the grammar rules given in gram.y would be
- beyond the scope of this paper. There are many books and
+ beyond the scope of this manual. There are many books and
documents dealing with flex and
bison. You should be familiar with
bison before you start to study the
@@ -343,8 +340,8 @@
In some situations, examining each possible way in which a query
- can be executed would take an excessive amount of time and memory
- space. In particular, this occurs when executing queries
+ can be executed would take an excessive amount of time and memory.
+ In particular, this occurs when executing queries
involving large numbers of join operations. In order to determine
a reasonable (not necessarily optimal) query plan in a reasonable amount
of time, PostgreSQL uses a Genetic
@@ -411,7 +408,7 @@
merge join: Each relation is sorted on the join
attributes before the join starts. Then the two relations are
scanned in parallel, and matching rows are combined to form
- join rows. This kind of join is more
+ join rows. This kind of join is
attractive because each relation has to be scanned only once.
The required sorting might be achieved either by an explicit sort
step, or by scanning the relation in the proper order using an
@@ -442,7 +439,7 @@
If the query uses fewer than
relations, a near-exhaustive search is conducted to find the best
join sequence. The planner preferentially considers joins between any
- two relations for which there exist a corresponding join clause in the
+ two relations for which there exists a corresponding join clause in the
WHERE qualification (i.e., for
which a restriction like where rel1.attr1=rel2.attr2
exists). Join pairs with no join clause are considered only when there