Skip to content

P
Postgres FD Implementation
Commit 33c5fce8 authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Update flowchart sections to match current CVS.

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