From a6ca652508c1d12ccc5b3ec0a9d80eea37e1d34c Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Mon, 20 Jul 1998 10:01:51 +0000
Subject: [PATCH] Update version.

---
 src/tools/backend/index.html | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html
index 2fb2a096af..626517293c 100644
--- a/src/tools/backend/index.html
+++ b/src/tools/backend/index.html
@@ -10,6 +10,7 @@ How PostgreSQL Processes a Query
 by Bruce Momjian
 </H2>
 <P>
+
 A query comes to the backend via data packets arriving through TCP/IP
 or Unix Domain sockets.   It is loaded into a string, and passed to
 the
@@ -22,12 +23,14 @@ identify the query type, and load the proper query-specific structure,
 like <A HREF="../../include/nodes/parsenodes.h">CreateStmt</A> or <A
 HREF="../../include/nodes/parsenodes.h">SelectStmt.</A>
 <P>
+
 The query is then identified as a <I>Utility</I> query or a more complex
 query.  A <I>Utility</I> query is processed by a query-specific function
 in <A HREF="../../backend/commands"> commands.</A> A complex query, like
 <I>SELECT, UPDATE,</I> and
 <I>DELETE</I> requires much more handling.
 <P>
+
 The parser takes a complex query, and creates a
 <A HREF="../../include/nodes/parsenodes.h">Query</A> structure that
 contains all the elements used by complex queries.  Query.qual holds the
@@ -39,6 +42,7 @@ are linked together to form the <I>range table</I> of the query, which is
 generated by <A HREF="../../backend/parser/parse_clause.c">
 makeRangeTable().</A>  Query.rtable holds the query's range table.
 <P>
+
 Certain queries, like <I>SELECT,</I> return columns of data.  Other
 queries, like <I>INSERT</I> and <I>UPDATE,</I> specify the columns
 modified by the query.  These column references are converted to <A
@@ -49,13 +53,16 @@ the query. The target list is stored in Query.targetList, which is
 generated by
 <A HREF="../../backend/parser/parse_target.c">transformTargetList().</A>
 <P>
+
 Other query elements, like aggregates(<I>SUM()</I>), <I>GROUP BY,</I>
 and <I>ORDER BY</I> are also stored in their own Query fields.
 <P>
+
 The next step is for the Query to be modified by any <I>VIEWS</I> or
 <I>RULES</I> that may apply to the query.  This is performed by the <A
 HREF="../../backend/rewrite">rewrite</A> system.
 <P>
+
 The <A HREF="../../backend/optimizer">optimizer</A> takes the Query
 structure and generates an optimal <A
 HREF="../..//include/nodes/plannodes.h">Plan,</A> which contains the
@@ -65,18 +72,21 @@ table join order and join type of each table in the RangeTable, using
 Query.qual(<I>WHERE</I> clause) to consider optimal index usage.
 <P>
 
+
 The Plan is then passed to the <A
 HREF="../../backend/executor">executor</A> for execution, and the result
 returned to the client.  The Plan actually as set of nodes, arranged in
 a tree structure with a top-level node, and various sub-nodes as
 children.
-
 <P>
+
 There are many other modules that support this basic functionality.
 They can be accessed by clicking on the flowchart.
 <P>
+
 <HR>
 <P>
+
 <CENTER>
 <EM><BIG>
 Click on an item to see more detail or look at the full
@@ -107,8 +117,10 @@ Click on an item to see more detail or look at the full
 </MAP>
 <BR>
 <P>
+
 <HR>
 <P>
+
 Another area of interest is the shared memory area, which contains data
 accessable to all backends.  It has table recently used data/index
 blocks, locks, backend information, and lookup tables for these
@@ -147,6 +159,7 @@ HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</A> and
 the lookups are created by
 <A HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A>
 <P>
+
 <HR SIZE="2" NOSHADE>
 <SMALL>
 <ADDRESS>