Update flowchart sections to match current CVS.

author: Bruce Momjian <bruce@momjian.us> 2005-05-06 19:07:17 +0000
committer: Bruce Momjian <bruce@momjian.us> 2005-05-06 19:07:17 +0000
commit: 33c5fce8db5b50645a789c339b745056c0c6f8a2 (patch)
tree: 3472d257bb518c8869e9c0686e288fad243ed840 /src
parent: 63ef676781d11bfff0e81e74a6929b09d45c5847 (diff)
download: postgresql-33c5fce8db5b50645a789c339b745056c0c6f8a2.tar.gz
postgresql-33c5fce8db5b50645a789c339b745056c0c6f8a2.zip
2 files changed, 360 insertions, 435 deletions
diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html
index 433324bff13..3c64f4f7cf5 100644
--- a/src/tools/backend/backend_dirs.html
+++ b/src/tools/backend/backend_dirs.html
@@ -1,428 +1,351 @@
-<HTML>
-<HEAD>
-<TITLE>PostgreSQL Backend Directories</TITLE>
-</HEAD>
-<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF">
-<H1>
-PostgreSQL Backend Directories
-</H1>
-<H2>
-by Bruce Momjian
-</H2>
-<HR>
-<P>
-<EM>Click on any of the section headings to see the source code for that section.
-</EM>
-</P>
-<H2>
-<A NAME="bootstrap"></A>
-<A HREF="../../backend/bootstrap">bootstrap</A>
-- creates initial template database via initdb
-</H2>
-<P>
-Because PostgreSQL requires access to system tables for almost every
-operation, getting those system tables in place is a problem.
-You can't just create the tables and insert data into them in the normal way,
-because table creation and insertion requires the tables to already
-exist.
-This code <I>jams</I> the data directly into tables using a
-special syntax used only by the bootstrap procedure.
-</P>
-<H2>
-<A NAME="main"></A>
-<A HREF="../../backend/main">main</A>
-- passes control to postmaster or postgres
-</H2>
-<P>
-This checks the process name(argv[0]) and various flags, and passes
-control to the postmaster or postgres backend code.
-</P>
-<H2>
-<A NAME="postmaster"></A>
-<A HREF="../../backend/postmaster">postmaster</A>
-- controls postgres server startup/termination
-</H2>
-<P>
-This creates shared memory, and then goes into a loop waiting for
-connection requests.
-When a connection request arrives, a <I>postgres</I> backend is started,
-and the connection is passed to it.
-</P>
-<H2>
-<A NAME="libpq"></A>
-<A HREF="../../backend/libpq">libpq</A>
-- backend libpq library routines
-</H2>
-<P>
-This handles communication to the client processes.
-</P>
-<H2>
-<A NAME="tcop"></A>
-<A HREF="../../backend/tcop">tcop</A>
-- traffic cop, dispatches request to proper module
-</H2>
-<P>
-This contains the <I>postgres</I> backend main handler, as well as the
-code that makes calls to the parser, optimizer, executor, and
-<I>/commands</I> functions.
-</P>
-<H2>
-<A NAME="parser"></A>
-<A HREF="../../backend/parser">parser</A>
-- converts SQL query to query tree
-</H2>
-<P>
-This converts SQL queries coming from <I>libpq</I> into command-specific
-structures to be used the the optimizer/executor, or <I>/commands</I>
-routines.
-The SQL is lexically analyzed into keywords, identifiers, and constants,
-and passed to the parser.
-The parser creates command-specific structures to hold the elements of
-the query.
-The command-specific structures are then broken apart, checked, and passed to
-<I>/commands</I> processing routines, or converted into <I>Lists</I> of 
-<I>Nodes</I> to be handled by the optimizer and executor.
-</P>
-<H2>
-<A NAME="optimizer"></A>
-<A HREF="../../backend/optimizer">optimizer</A>
-- creates path and plan
-</H2>
-<P>
-This uses the parser output to generate an optimal plan for the
-executor.
-</P>
-<H3>
-<A NAME="optimizer_path"></A>
-<A HREF="../../backend/optimizer/path">optimizer/path</A>
-- creates path from parser output
-</H3>
-<P>
-This takes the parser query output, and generates all possible methods of
-executing the request.
-It examines table join order, <I>where</I> clause restrictions,
-and optimizer table statistics to evaluate each possible execution
-method, and assigns a cost to each.
-</P>
-<H3>
-<A NAME="optimizer_geqo"></A>
-<A HREF="../../backend/optimizer/geqo">optimizer/geqo</A>
-- genetic query optimizer
-</H3>
-<P>
-<I>optimizer/path</I> evaluates all possible ways to join the requested tables.
-When the number of tables becomes great, the number of tests made
-becomes great too.
-The Genetic Query Optimizer considers each table separately, then figures
-the most optimal order to perform the join.
-For a few tables, this method takes longer, but for a large number of
-tables, it is faster.
-There is an option to control when this feature is used.
-</P>
-<H3>
-<A NAME="optimizer_plan"></A>
-<A HREF="../../backend/optimizer/plan">optimizer/plan</A>
-- optimizes path output
-</H3>
-<P>
-This takes the <I>optimizer/path</I> output, chooses the path with the
-least cost, and creates a plan for the executor.
-</P>
-<H3>
-<A NAME="optimizer_prep"></A>
-<A HREF="../../backend/optimizer/prep">optimizer/prep</A>
-- handle special plan cases
-</H3>
-<P>
-This does special plan processing.
-</P>
-<H3>
-<A NAME="optimizer_util"></A>
-<A HREF="../../backend/optimizer/util">optimizer/util</A>
-- optimizer support routines
-</H3>
-<P>
-This contains support routines used by other parts of the optimizer.
-</P>
-<H2>
-<A NAME="executor"></A>
-<A HREF="../../backend/executor">executor</A>
-- executes complex node plans from optimizer
-</H2>
-<P>
-This handles <I>select, insert, update,</I> and <I>delete</I> statements.
-The operations required to handle these statement types include
-heap scans, index scans, sorting, joining tables, grouping, aggregates,
-and uniqueness.
-</P>
-<H2>
-<A NAME="commands"></A>
-<A HREF="../../backend/commands">commands</A>
-- commands that do not require the executor
-</H2>
-<P>
-These process SQL commands that do not require complex handling.
-It includes <I>vacuum, copy, alter, create table, create type,</I> and
-many others.
-The code is called with the structures generated by the parser.
-Most of the routines do some processing, then call lower-level functions
-in the catalog directory to do the actual work.
-</P>
-<H2>
-<A NAME="catalog"></A>
-<A HREF="../../backend/catalog">catalog</A>
-- system catalog manipulation
-</H2>
-<P>
-This contains functions that manipulate the system tables or catalogs.
-Table, index, procedure, operator, type, and aggregate creation and
-manipulation routines are here.
-These are low-level routines, and are usually called by upper routines
-that pre-format user requests into a predefined format.
-</P>
-<H2>
-<A NAME="storage"></A>
-<A HREF="../../backend/storage">storage</A>
-- manages various storage systems
-</H2>
-<P>
-These allow uniform resource access by the backend.
-<BR>
-<BR>
-<A NAME="storage_buffer"></A>
-<A HREF="../../backend/storage/buffer">storage/buffer</A>
-- shared buffer pool manager
-<BR>
-<A NAME="storage_file"></A>
-<A HREF="../../backend/storage/file">storage/file</A>
-- file manager
-<BR>
-<A NAME="storage_ipc"></A>
-<A HREF="../../backend/storage/ipc">storage/ipc</A>
-- semaphores and shared memory
-<BR>
-<A NAME="storage_large_object"></A>
-<A HREF="../../backend/storage/large_object">storage/large_object</A>
-- large objects
-<BR>
-<A NAME="storage_lmgr"></A>
-<A HREF="../../backend/storage/lmgr">storage/lmgr</A>
-- lock manager
-<BR>
-<A NAME="storage_page"></A>
-<A HREF="../../backend/storage/page">storage/page</A>
-- page manager
-<BR>
-<A NAME="storage_smgr"></A>
-<A HREF="../../backend/storage/smgr">storage/smgr</A>
-- storage/disk manager
-<BR>
-<BR>
-</P>
-<H2>
-<A NAME="access"></A>
-<A HREF="../../backend/access">access</A>
-- various data access methods
-</H2>
-<P>
-These control the way data is accessed in heap, indexes, and
-transactions.
-<BR>
-<BR>
-<A NAME="access_common"></A>
-<A HREF="../../backend/access/common">access/common</A>
-- common access routines
-<BR>
-<A NAME="access_gist"></A>
-<A HREF="../../backend/access/gist">access/gist</A>
-- easy-to-define access method system
-<BR>
-<A NAME="access_hash"></A>
-<A HREF="../../backend/access/hash">access/hash</A>
-- hash
-<BR>
-<A NAME="access_heap"></A>
-<A HREF="../../backend/access/heap">access/heap</A>
-- heap is use to store data rows
-<BR>
-<A NAME="access_index"></A>
-<A HREF="../../backend/access/index">access/index</A>
-- used by all index types
-<BR>
-<A NAME="access_nbtree"></A>
-<A HREF="../../backend/access/nbtree">access/nbtree</A>
-- Lehman and Yao's btree management algorithm 
-<BR>
-<A NAME="access_rtree"></A>
-<A HREF="../../backend/access/rtree">access/rtree</A>
-- used for indexing of 2-dimensional data
-<BR>
-<A NAME="access_transam"></A>
-<A HREF="../../backend/access/transam">access/transam</A>
-- transaction manager (BEGIN/ABORT/COMMIT)
-<BR>
-<BR>
-</P>
-<H2>
-<A NAME="nodes"></A>
-<A HREF="../../backend/nodes">nodes</A>
-- creation/manipulation of nodes and lists
-</H2>
-<P>
-PostgreSQL stores information about SQL queries in structures called
-nodes.
-<I>Nodes</I> are generic containers that have a <I>type</I> field and then a
-type-specific data section.
-Nodes are usually placed in <I>Lists.</I>
-A <I>List</I> is container with an <I>elem</I> element,
-and a <I>next</I> field that points to the next <I>List.</I>
-These <I>List</I> structures are chained together in a forward linked list.
-In this way, a chain of <I>List</I>s can contain an unlimited number of <I>Node</I>
-elements, and each <I>Node</I> can contain any data type.
-These are used extensively in the parser, optimizer, and executor to
-store requests and data.
-</P>
-<H2>
-<A NAME="utils"></A>
-<A HREF="../../backend/utils">utils</A>
-- support routines
-</H2>
-<H3>
-<A NAME="utils_adt"></A>
-<A HREF="../../backend/utils/adt">utils/adt</A>
-- built-in data type routines
-</H3>
-<P>
-This contains all the PostgreSQL builtin data types.
-</P>
-<H3>
-<A NAME="utils_cache"></A>
-<A HREF="../../backend/utils/cache">utils/cache</A>
-- system/relation/function cache routines
-</H3>
-<P>
-PostgreSQL supports arbitrary data types, so no data types are hard-coded
-into the core backend routines.
-When the backend needs to find out about a type, is does a lookup of a
-system table.
-Because these system tables are referred to often, a cache is maintained
-that speeds lookups.
-There is a system relation cache, a function/operator cache, and a relation
-information cache.
-This last cache maintains information about all recently-accessed
-tables, not just system ones.
-</P>
-<H3>
-<A NAME="utils_error"></A>
-<A HREF="../../backend/utils/error">utils/error</A>
-- error reporting routines
-</H3>
-<P>
-Reports backend errors to the front end.
-</P>
-<H3>
-<A NAME="utils_fmgr"></A>
-<A HREF="../../backend/utils/fmgr">utils/fmgr</A>
-- function manager
-</H3>
-<P>
-This handles the calling of dynamically-loaded functions, and the calling
-of functions defined in the system tables.
-</P>
-<H3>
-<A NAME="utils_hash"></A>
-<A HREF="../../backend/utils/hash">utils/hash</A>
-- hash routines for internal algorithms
-</H3>
-<P>
-These hash routines are used by the cache and memory-manager routines to
-do quick lookups of dynamic data storage structures maintained by the
-backend.
-</P>
-<H3>
-<A NAME="utils_init"></A>
-<A HREF="../../backend/utils/init">utils/init</A>
-- various initialization stuff
-</H3>
-<H3>
-<A NAME="utils_misc"></A>
-<A HREF="../../backend/utils/misc">utils/misc</A>
-- miscellaneous stuff
-</H3>
-<H3>
-<A NAME="utils_mmgr"></A>
-<A HREF="../../backend/utils/mmgr">utils/mmgr</A>
-- memory manager(process-local memory)
-</H3>
-<P>
-When PostgreSQL allocates memory, it does so in an explicit context.
-Contexts can be statement-specific, transaction-specific, or
-persistent/global.
-By doing this, the backend can easily free memory once a statement or
-transaction completes.
-</P>
-<H3>
-<A NAME="utils_sort"></A>
-<A HREF="../../backend/utils/sort">utils/sort</A>
-- sort routines for internal algorithms
-</H3>
-<P>
-When statement output must be sorted as part of a backend operation,
-this code sorts the tuples, either in memory or using disk files.
-</P>
-<H3>
-<A NAME="utils_time"></A>
-<A HREF="../../backend/utils/time">utils/time</A>
-- transaction time qualification routines
-</H3>
-<P>
-These routines do checking of tuple internal columns to determine if the
-current row is still valid, or is part of a non-committed transaction or
-superseded by a new row.
-</P>
-<H2>
-<A NAME="include"></A>
-<A HREF="../../backend/include">include</A>
-- include files
-</H2>
-<P>
-There are include directories for each subsystem.
-</P>
-<H2>
-<A NAME="lib"></A>
-<A HREF="../../backend/lib">lib</A>
-- support library
-</H2>
-<P>
-This houses several generic routines.
-</P>
-<H2>
-<A NAME="regex"></A>
-<A HREF="../../backend/regex">regex</A>
-- regular expression library
-</H2>
-<P>
-This is used for regular expression handling in the backend, i.e. '~'.
-</P>
-<H2>
-<A NAME="rewrite"></A>
-<A HREF="../../backend/rewrite">rewrite</A>
-- rules system
-</H2>
-<P>
-This does processing for the rules system.
-</P>
-<H2>
-<A NAME="tioga"></A>
-<A HREF="../../backend/tioga">tioga</A>
-- unused (array handling?)
-</H2>
-<BR>
-<HR>
-<SMALL>
-Maintainer:	Bruce Momjian (<A
-HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
-Last updated:		Tue Dec  9 17:56:08 EST 1997
-</SMALL>
-</BODY>
-</HTML>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta name="generator"
+content="HTML Tidy for BSD/OS (vers 1st July 2002), see www.w3.org" />
+<title>PostgreSQL Backend Directories</title>
+</head>
+<body bgcolor="#FFFFFF" text="#000000" link="#FF0000"
+vlink="#A00000" alink="#0000FF">
+<h1>PostgreSQL Backend Directories</h1>
+
+<h2>by Bruce Momjian</h2>
+
+<hr />
+<p><em>Click on any of the section headings to see the source code
+for that section.</em></p>
+
+<h2><a id="bootstrap" name="bootstrap"></a> <a
+href="../../backend/bootstrap">bootstrap</a> - creates initial
+template database via initdb</h2>
+
+<p>Because PostgreSQL requires access to system tables for almost
+every operation, getting those system tables in place is a problem.
+You can't just create the tables and insert data into them in the
+normal way, because table creation and insertion requires the
+tables to already exist. This code <i>jams</i> the data directly
+into tables using a special syntax used only by the bootstrap
+procedure.</p>
+
+<h2><a id="main" name="main"></a> <a
+href="../../backend/main">main</a> - passes control to postmaster
+or postgres</h2>
+
+<p>This checks the process name(argv[0]) and various flags, and
+passes control to the postmaster or postgres backend code.</p>
+
+<h2><a id="postmaster" name="postmaster"></a> <a
+href="../../backend/postmaster">postmaster</a> - controls postgres
+server startup/termination</h2>
+
+<p>This creates shared memory, and then goes into a loop waiting
+for connection requests. When a connection request arrives, a
+<i>postgres</i> backend is started, and the connection is passed to
+it.</p>
+
+<h2><a id="libpq" name="libpq"></a> <a
+href="../../backend/libpq">libpq</a> - backend libpq library
+routines</h2>
+
+<p>This handles communication to the client processes.</p>
+
+<h2><a id="tcop" name="tcop"></a> <a
+href="../../backend/tcop">tcop</a> - traffic cop, dispatches
+request to proper module</h2>
+
+<p>This contains the <i>postgres</i> backend main handler, as well
+as the code that makes calls to the parser, optimizer, executor,
+and <i>/commands</i> functions.</p>
+
+<h2><a id="parser" name="parser"></a> <a
+href="../../backend/parser">parser</a> - converts SQL query to
+query tree</h2>
+
+<p>This converts SQL queries coming from <i>libpq</i> into
+command-specific structures to be used the the optimizer/executor,
+or <i>/commands</i> routines. The SQL is lexically analyzed into
+keywords, identifiers, and constants, and passed to the parser. The
+parser creates command-specific structures to hold the elements of
+the query. The command-specific structures are then broken apart,
+checked, and passed to <i>/commands</i> processing routines, or
+converted into <i>Lists</i> of <i>Nodes</i> to be handled by the
+optimizer and executor.</p>
+
+<h2><a id="rewrite" name="rewrite"></a> <a
+href="../../backend/rewrite">rewrite</a> - rule and views support</h2>
+
+<h2><a id="optimizer" name="optimizer"></a> <a
+href="../../backend/optimizer">optimizer</a> - creates path and
+plan</h2>
+
+<p>This uses the parser output to generate an optimal plan for the
+executor.</p>
+
+<h3><a id="optimizer_path" name="optimizer_path"></a> <a
+href="../../backend/optimizer/path">optimizer/path</a> - creates
+path from parser output</h3>
+
+<p>This takes the parser query output, and generates all possible
+methods of executing the request. It examines table join order,
+<i>where</i> clause restrictions, and optimizer table statistics to
+evaluate each possible execution method, and assigns a cost to
+each.</p>
+
+<h3><a id="optimizer_geqo" name="optimizer_geqo"></a> <a
+href="../../backend/optimizer/geqo">optimizer/geqo</a> - genetic
+query optimizer</h3>
+
+<p><i>optimizer/path</i> evaluates all possible ways to join the
+requested tables. When the number of tables becomes great, the
+number of tests made becomes great too. The Genetic Query Optimizer
+considers each table separately, then figures the most optimal
+order to perform the join. For a few tables, this method takes
+longer, but for a large number of tables, it is faster. There is an
+option to control when this feature is used.</p>
+
+<h3><a id="optimizer_plan" name="optimizer_plan"></a> <a
+href="../../backend/optimizer/plan">optimizer/plan</a> - optimizes
+path output</h3>
+
+<p>This takes the <i>optimizer/path</i> output, chooses the path
+with the least cost, and creates a plan for the executor.</p>
+
+<h3><a id="optimizer_prep" name="optimizer_prep"></a> <a
+href="../../backend/optimizer/prep">optimizer/prep</a> - handle
+special plan cases</h3>
+
+<p>This does special plan processing.</p>
+
+<h3><a id="optimizer_util" name="optimizer_util"></a> <a
+href="../../backend/optimizer/util">optimizer/util</a> - optimizer
+support routines</h3>
+
+<p>This contains support routines used by other parts of the
+optimizer.</p>
+
+<h2><a id="executor" name="executor"></a> <a
+href="../../backend/executor">executor</a> - executes complex node
+plans from optimizer</h2>
+
+<p>This handles <i>select, insert, update,</i> and <i>delete</i>
+statements. The operations required to handle these statement types
+include heap scans, index scans, sorting, joining tables, grouping,
+aggregates, and uniqueness.</p>
+
+<h2><a id="commands" name="commands"></a> <a
+href="../../backend/commands">commands</a> - commands that do not
+require the executor</h2>
+
+<p>These process SQL commands that do not require complex handling.
+It includes <i>vacuum, copy, alter, create table, create type,</i>
+and many others. The code is called with the structures generated
+by the parser. Most of the routines do some processing, then call
+lower-level functions in the catalog directory to do the actual
+work.</p>
+
+<h2><a id="catalog" name="catalog"></a> <a
+href="../../backend/catalog">catalog</a> - system catalog
+manipulation</h2>
+
+<p>This contains functions that manipulate the system tables or
+catalogs. Table, index, procedure, operator, type, and aggregate
+creation and manipulation routines are here. These are low-level
+routines, and are usually called by upper routines that pre-format
+user requests into a predefined format.</p>
+
+<h2><a id="storage" name="storage"></a> <a
+href="../../backend/storage">storage</a> - manages various storage
+systems</h2>
+
+<p>These allow uniform resource access by the backend.<br />
+<br />
+<a id="storage_buffer" name="storage_buffer"></a> <a
+href="../../backend/storage/buffer">storage/buffer</a> - shared
+buffer pool manager<br />
+<a id="storage_file" name="storage_file"></a> <a
+href="../../backend/storage/file">storage/file</a> - file
+manager<br />
+<a id="storage_file" name="storage_freespace"></a> <a
+href="../../backend/storage/freespace">storage/freespace</a> - free
+space map<br />
+<a id="storage_ipc" name="storage_ipc"></a> <a
+href="../../backend/storage/ipc">storage/ipc</a> - semaphores and
+shared memory<br />
+<a id="storage_large_object" name="storage_large_object"></a> <a
+href="../../backend/storage/large_object">storage/large_object</a>
+- large objects<br />
+<a id="storage_lmgr" name="storage_lmgr"></a> <a
+href="../../backend/storage/lmgr">storage/lmgr</a> - lock
+manager<br />
+<a id="storage_page" name="storage_page"></a> <a
+href="../../backend/storage/page">storage/page</a> - page
+manager<br />
+<a id="storage_smgr" name="storage_smgr"></a> <a
+href="../../backend/storage/smgr">storage/smgr</a> - storage/disk
+manager<br />
+<br />
+</p>
+
+<h2><a id="access" name="access"></a> <a
+href="../../backend/access">access</a> - various data access
+methods</h2>
+
+<p>These control the way data is accessed in heap, indexes, and
+transactions.<br />
+<br />
+<a id="access_common" name="access_common"></a> <a
+href="../../backend/access/common">access/common</a> - common
+access routines<br />
+<a id="access_gist" name="access_gist"></a> <a
+href="../../backend/access/gist">access/gist</a> - easy-to-define
+access method system<br />
+<a id="access_hash" name="access_hash"></a> <a
+href="../../backend/access/hash">access/hash</a> - hash<br />
+<a id="access_heap" name="access_heap"></a> <a
+href="../../backend/access/heap">access/heap</a> - heap is use to
+store data rows<br />
+<a id="access_index" name="access_index"></a> <a
+href="../../backend/access/index">access/index</a> - used by all
+index types<br />
+<a id="access_nbtree" name="access_nbtree"></a> <a
+href="../../backend/access/nbtree">access/nbtree</a> - Lehman and
+Yao's btree management algorithm<br />
+<a id="access_rtree" name="access_rtree"></a> <a
+href="../../backend/access/rtree">access/rtree</a> - used for
+indexing of 2-dimensional data<br />
+<a id="access_transam" name="access_transam"></a> <a
+href="../../backend/access/transam">access/transam</a> -
+transaction manager (BEGIN/ABORT/COMMIT)<br />
+<br />
+</p>
+
+<h2><a id="nodes" name="nodes"></a> <a
+href="../../backend/nodes">nodes</a> - creation/manipulation of
+nodes and lists</h2>
+
+<p>PostgreSQL stores information about SQL queries in structures
+called nodes. <i>Nodes</i> are generic containers that have a
+<i>type</i> field and then a type-specific data section. Nodes are
+usually placed in <i>Lists.</i> A <i>List</i> is container with an
+<i>elem</i> element, and a <i>next</i> field that points to the
+next <i>List.</i> These <i>List</i> structures are chained together
+in a forward linked list. In this way, a chain of <i>List</i>s can
+contain an unlimited number of <i>Node</i> elements, and each
+<i>Node</i> can contain any data type. These are used extensively
+in the parser, optimizer, and executor to store requests and
+data.</p>
+
+<h2><a id="utils" name="utils"></a> <a
+href="../../backend/utils">utils</a> - support routines</h2>
+
+<h3><a id="utils_adt" name="utils_adt"></a> <a
+href="../../backend/utils/adt">utils/adt</a> - built-in data type
+routines</h3>
+
+<p>This contains all the PostgreSQL builtin data types.</p>
+
+<h3><a id="utils_cache" name="utils_cache"></a> <a
+href="../../backend/utils/cache">utils/cache</a> -
+system/relation/function cache routines</h3>
+
+<p>PostgreSQL supports arbitrary data types, so no data types are
+hard-coded into the core backend routines. When the backend needs
+to find out about a type, is does a lookup of a system table.
+Because these system tables are referred to often, a cache is
+maintained that speeds lookups. There is a system relation cache, a
+function/operator cache, and a relation information cache. This
+last cache maintains information about all recently-accessed
+tables, not just system ones.</p>
+
+<h3><a id="utils_error" name="utils_error"></a> <a
+href="../../backend/utils/error">utils/error</a> - error reporting
+routines</h3>
+
+<p>Reports backend errors to the front end.</p>
+
+<h3><a id="utils_fmgr" name="utils_fmgr"></a> <a
+href="../../backend/utils/fmgr">utils/fmgr</a> - function
+manager</h3>
+
+<p>This handles the calling of dynamically-loaded functions, and
+the calling of functions defined in the system tables.</p>
+
+<h3><a id="utils_hash" name="utils_hash"></a> <a
+href="../../backend/utils/hash">utils/hash</a> - hash routines for
+internal algorithms</h3>
+
+<p>These hash routines are used by the cache and memory-manager
+routines to do quick lookups of dynamic data storage structures
+maintained by the backend.</p>
+
+<h3><a id="utils_init" name="utils_init"></a> <a
+href="../../backend/utils/init">utils/init</a> - various
+initialization stuff</h3>
+
+<h3><a id="utils_misc" name="utils_mb"></a> <a
+href="../../backend/utils/mb">utils/mb</a> - single and
+multibyte encoding</h3>
+
+<h3><a id="utils_misc" name="utils_misc"></a> <a
+href="../../backend/utils/misc">utils/misc</a> - miscellaneous
+stuff</h3>
+
+<h3><a id="utils_mmgr" name="utils_mmgr"></a> <a
+href="../../backend/utils/mmgr">utils/mmgr</a> - memory
+manager(process-local memory)</h3>
+
+<p>When PostgreSQL allocates memory, it does so in an explicit
+context. Contexts can be statement-specific, transaction-specific,
+or persistent/global. By doing this, the backend can easily free
+memory once a statement or transaction completes.</p>
+
+<h3><a id="utils_mmgr" name="utils_resowner"></a> <a
+href="../../backend/utils/resowner">utils/resowner</a> - resource
+owner tracking</h3>
+
+<h3><a id="utils_sort" name="utils_sort"></a> <a
+href="../../backend/utils/sort">utils/sort</a> - sort routines for
+internal algorithms</h3>
+
+<p>When statement output must be sorted as part of a backend
+operation, this code sorts the tuples, either in memory or using
+disk files.</p>
+
+<h3><a id="utils_time" name="utils_time"></a> <a
+href="../../backend/utils/time">utils/time</a> - transaction time
+qualification routines</h3>
+
+<p>These routines do checking of tuple internal columns to
+determine if the current row is still valid, or is part of a
+non-committed transaction or superseded by a new row.</p>
+
+<h2><a id="include" name="include"></a> <a
+href="../../backend/include">include</a> - include files</h2>
+
+<p>There are include directories for each subsystem.</p>
+
+<h2><a id="lib" name="lib"></a> <a href="../../backend/lib">lib</a>
+- support library</h2>
+
+<p>This houses several generic routines.</p>
+
+<h2><a id="regex" name="regex"></a> <a
+href="../../backend/regex">regex</a> - regular expression
+library</h2>
+
+<p>This is used for regular expression handling in the backend,
+i.e. '~'.</p>
+
+<h2><a id="rewrite" name="port"></a> <a
+href="../../backend/port">port</a> - compatibility routines</h2>
+
+<br />
+<hr />
+<small>Maintainer: Bruce Momjian (<a
+href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br />
+
+Last updated: Fri May 6 14:22:27 EDT 2005</small>
+</body>
+</html>
+
diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html
index 0e80fd13205..af255f912fe 100644
--- a/src/tools/backend/index.html
+++ b/src/tools/backend/index.html
@@ -12,10 +12,11 @@ vlink="#A00000" alink="#0000FF">
 
 <h2>by Bruce Momjian</h2>
 
-<p><img src="flow.gif" usemap="#flowmap" alt="flowchart" />
+<center>
+<h3>Click on an item to see more detail or look at the full
+<a href="backend_dirs.html">index.</a></h3>
 
-<center><h3>Click on an item to see more detail or look at the full
-<a href="backend_dirs.html">index.</a></h3></center>
+<p><img src="flow.gif" usemap="#flowmap" alt="flowchart" />
 
 <map name="flowmap" id="flowmap">
 <area coords="125,35,245,65" href="backend_dirs.html#main" alt="main" />
@@ -36,6 +37,7 @@ vlink="#A00000" alink="#0000FF">
 <area coords="325,635,450,665" href="backend_dirs.html#nodes" alt="nodes" />
 <area coords="75,705,200,730" href="backend_dirs.html#bootstrap" alt="bootstrap" />
 </map>
+</center>
 
 <br />
 
@@ -52,9 +54,9 @@ href="../../include/nodes/parsenodes.h">SelectStmt.</a></p>
 
 <p>The statement is then identified as complex (<i>SELECT / INSERT /
 UPDATE / DELETE</i>) or a simple, e.g <i> CREATE USER, ANALYZE, </i>,
-etc.  Utility commands are processed by statement-specific functions in <a
-href="../../backend/commands">backend/commands.</a> Complex statements
-require more handling.</p>
+etc.  Simple utility commands are processed by statement-specific
+functions in <a href="../../backend/commands">backend/commands.</a>
+Complex statements require more handling.</p>
 
 <p>The parser takes a complex query, and creates a <a
 href="../../include/nodes/parsenodes.h">Query</a> structure that
@@ -98,7 +100,7 @@ optimal index usage.</p>
 
 <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,
+result returned to the client. The Plan is actually as set of nodes,
 arranged in a tree structure with a top-level node, and various
 sub-nodes as children.</p>
author	Bruce Momjian <bruce@momjian.us>	2005-05-06 19:07:17 +0000
committer	Bruce Momjian <bruce@momjian.us>	2005-05-06 19:07:17 +0000
commit	33c5fce8db5b50645a789c339b745056c0c6f8a2 (patch)
tree	3472d257bb518c8869e9c0686e288fad243ed840 /src
parent	63ef676781d11bfff0e81e74a6929b09d45c5847 (diff)
download	postgresql-33c5fce8db5b50645a789c339b745056c0c6f8a2.tar.gz postgresql-33c5fce8db5b50645a789c339b745056c0c6f8a2.zip