mirror of
https://github.com/postgres/postgres.git
synced 2025-05-31 00:01:57 -04:00
Update flowchart sections to match current CVS.
This commit is contained in:
Bruce Momjian
parent
63ef676781
commit
33c5fce8db
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user