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>
<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>
src/tools/backend/index.html
View file @ 33c5fce8
......@@ -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>
......
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