mirror of https://github.com/postgres/postgres
Bruce Momjian
13 years ago
parent
2042185baf
commit
63f1ccd838
@ -1,4 +0,0 @@ |
||||
src/tools/backend/README |
||||
|
||||
Just point your browser at the index.html file, and click on the |
||||
flowchart to see the description and source code. |
||||
@ -1,349 +0,0 @@ |
||||
<!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 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_freespace" 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_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_mb" 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_resowner" 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="port" 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> |
||||
@ -1,143 +0,0 @@ |
||||
#FIG 3.2 Produced by xfig version 3.2.5 |
||||
Portrait |
||||
Center |
||||
Inches |
||||
Letter |
||||
88.00 |
||||
Single |
||||
-2 |
||||
1200 2 |
||||
0 32 #919191 |
||||
0 33 #c5ddc1 |
||||
2 4 0 1 -1 26 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 900 1200 900 1200 300 3600 300 3600 900 |
||||
2 4 0 1 -1 4 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 2100 1200 2100 1200 1500 3600 1500 3600 2100 |
||||
2 4 0 1 -1 0 1 0 20 0.000 0 0 7 0 0 5 |
||||
7500 1500 5100 1500 5100 900 7500 900 7500 1500 |
||||
2 4 0 1 -1 31 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 3300 1200 3300 1200 2700 3600 2700 3600 3300 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 6000 1200 6000 1200 5400 3600 5400 3600 6000 |
||||
2 4 0 1 -1 31 1 0 20 0.000 0 0 7 0 0 5 |
||||
7500 3300 5100 3300 5100 2700 7500 2700 7500 3300 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 8400 1200 8400 1200 7800 3600 7800 3600 8400 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 9600 1200 9600 1200 9000 3600 9000 3600 9600 |
||||
2 1 2 2 -1 7 0 0 -1 3.000 0 1 -1 1 1 2 |
||||
0 0 2.00 80.00 150.00 |
||||
0 0 2.00 80.00 150.00 |
||||
4500 1425 5135 1194 |
||||
2 1 2 2 -1 7 0 0 -1 4.000 0 1 -1 1 1 2 |
||||
0 0 2.00 80.00 150.00 |
||||
0 0 2.00 80.00 150.00 |
||||
4725 2025 5160 1467 |
||||
2 1 0 2 20 7 1 0 -1 0.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 2100 2400 2700 |
||||
2 1 0 2 31 7 1 0 -1 0.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 3300 2400 4275 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 7200 1200 7200 1200 6600 3600 6600 3600 7200 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 10800 1200 10800 1200 10200 3600 10200 3600 10800 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
3600 4800 1200 4800 1200 4200 3600 4200 3600 4800 |
||||
2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 8400 2400 9000 |
||||
2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 7200 2400 7800 |
||||
2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 6000 2400 6600 |
||||
2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 4800 2400 5400 |
||||
2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
3600 5700 5100 5700 |
||||
2 1 0 2 25 7 0 0 -1 0.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.50 |
||||
2400 900 2400 1500 |
||||
2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5 |
||||
7500 6000 5100 6000 5100 5400 7500 5400 7500 6000 |
||||
2 4 0 1 33 33 3 0 20 0.000 0 0 40 0 0 5 |
||||
8700 11100 300 11100 300 3600 8700 3600 8700 11100 |
||||
2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2 |
||||
0 0 2.00 150.00 180.00 |
||||
0 0 2.00 150.00 180.00 |
||||
3150 13050 3150 13650 |
||||
2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2 |
||||
0 0 2.00 150.00 180.00 |
||||
0 0 2.00 150.00 180.00 |
||||
1500 12450 1500 11850 |
||||
2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5 |
||||
2700 13050 300 13050 300 12450 2700 12450 2700 13050 |
||||
2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5 |
||||
6000 13050 3600 13050 3600 12450 6000 12450 6000 13050 |
||||
2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5 |
||||
7500 14250 5100 14250 5100 13650 7500 13650 7500 14250 |
||||
2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5 |
||||
4200 14250 1800 14250 1800 13650 4200 13650 4200 14250 |
||||
2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2 |
||||
0 0 2.00 150.00 180.00 |
||||
0 0 2.00 150.00 180.00 |
||||
4800 12450 4800 11850 |
||||
2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2 |
||||
0 0 2.00 150.00 180.00 |
||||
0 0 2.00 150.00 180.00 |
||||
6300 13050 6300 13650 |
||||
2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5 |
||||
9300 13050 6600 13050 6600 12450 9300 12450 9300 13050 |
||||
2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2 |
||||
0 0 2.00 150.00 180.00 |
||||
0 0 2.00 150.00 180.00 |
||||
7950 11850 7950 12450 |
||||
2 1 1 2 5 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 6000 2400 6600 |
||||
2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2 |
||||
0 0 2.00 150.00 180.00 |
||||
2400 9600 2400 10200 |
||||
3 2 2 2 20 7 0 0 -1 6.000 1 1 0 5 |
||||
0 0 2.00 150.00 180.00 |
||||
2415 2140 3090 2440 5265 2515 6090 2590 6315 2740 |
||||
0.000 -1.000 -1.000 -1.000 0.000 |
||||
3 0 1 2 32 7 1 0 -1 4.500 0 1 0 7 |
||||
0 0 2.00 150.00 150.00 |
||||
7500 5700 8400 5400 8400 4500 7800 3900 3600 3900 3000 3900 |
||||
2700 4200 |
||||
0.000 1.000 1.000 1.000 1.000 1.000 0.000 |
||||
3 0 1 2 32 7 0 0 -1 4.000 0 1 0 8 |
||||
0 0 2.00 150.00 150.00 |
||||
1125 10500 900 10350 675 9975 675 4350 900 3975 1350 3900 |
||||
1800 3900 2100 4200 |
||||
0.000 1.000 1.000 1.000 1.000 1.000 1.000 0.000 |
||||
4 1 5 2 0 28 18 0.0000 4 285 870 4350 5625 utility\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 210 1455 2400 1950 Postmaster\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 270 1125 2400 3150 Postgres\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 270 1125 6300 3150 Postgres\001 |
||||
4 1 7 0 0 16 18 0.0000 4 270 720 6300 1350 Libpq\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 210 615 2400 750 Main\001 |
||||
4 1 7 0 0 16 18 0.0000 4 210 1815 2400 9450 Generate Plan\001 |
||||
4 1 7 0 0 16 18 0.0000 4 270 1440 2400 5850 Traffic Cop\001 |
||||
4 1 7 0 0 16 18 0.0000 4 210 1980 2400 8250 Generate Paths\001 |
||||
4 1 5 2 0 28 18 0.0000 4 225 615 2400 9900 Plan\001 |
||||
4 1 5 2 0 28 18 0.0000 4 285 1920 2400 8700 Optimal Path\001 |
||||
4 1 5 2 0 28 18 0.0000 4 285 900 2400 6300 Query\001 |
||||
4 1 7 0 0 16 18 0.0000 4 210 1680 2400 10650 Execute Plan\001 |
||||
4 0 5 0 0 16 12 0.0000 4 210 2640 5250 6300 e.g. CREATE TABLE, COPY\001 |
||||
4 1 5 0 0 16 12 0.0000 4 195 3540 2400 6525 SELECT, INSERT, UPDATE, DELETE\001 |
||||
4 1 7 0 0 16 18 0.0000 4 270 1800 2400 7050 Rewrite Query\001 |
||||
4 1 7 0 0 16 18 0.0000 4 210 2130 2400 4650 Parse Statement\001 |
||||
4 1 7 0 0 16 18 0.0000 4 270 720 6300 5700 Utility\001 |
||||
4 1 7 0 0 16 18 0.0000 4 210 1335 6300 6000 Command\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 270 2355 7950 12900 Storage Managers\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 270 1020 4800 12900 Catalog\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 210 915 1500 12900 Utilities\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 210 2085 3000 14100 Access Methods\001 |
||||
4 1 -1 0 0 16 18 0.0000 4 210 1635 6300 14100 Nodes / Lists\001 |
||||
|
Before Width: | Height: | Size: 490 KiB |
@ -1,155 +0,0 @@ |
||||
<!-- src/tools/backend/index.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>How PostgreSQL Processes a Query</title> |
||||
</head> |
||||
<body bgcolor="#FFFFFF" text="#000000" link="#FF0000" |
||||
vlink="#A00000" alink="#0000FF"> |
||||
<h1>How PostgreSQL Processes a Query</h1> |
||||
|
||||
<h2>by Bruce Momjian</h2> |
||||
|
||||
<center> |
||||
<h3><i>Click on an item</i> to see more detail or look at the full |
||||
<a href="backend_dirs.html">index.</a></h3> |
||||
|
||||
<p><img src="flow.gif" usemap="#flowmap" alt="flowchart" /> |
||||
|
||||
<map name="flowmap" id="flowmap"> |
||||
<area coords="45, 0, 175, 30" href="backend_dirs.html#main" alt="main" /> |
||||
<area coords="255, 35, 380, 65" href="backend_dirs.html#libpq" alt="libpq" /> |
||||
<area coords="45, 65, 175, 95" href="backend_dirs.html#postmaster" alt="postmaster" /> |
||||
<area coords="45, 130, 175, 160" href="backend_dirs.html#tcop" alt="tcop" /> |
||||
<area coords="250, 130, 380, 160" href="backend_dirs.html#tcop" alt="tcop" /> |
||||
<area coords="45, 205, 175, 240" href="backend_dirs.html#parser" alt="parser" /> |
||||
<area coords="45, 270, 175, 300" href="backend_dirs.html#tcop" alt="tcop" /> |
||||
<area coords="255, 270, 380, 300" href="backend_dirs.html#commands" alt="commands" /> |
||||
<area coords="45, 335, 175, 365" href="backend_dirs.html#rewrite" alt="rewrite" /> |
||||
<area coords="45, 400, 175, 430" href="backend_dirs.html#optimizer_path" alt="path" /> |
||||
<area coords="45, 460, 175, 490" href="backend_dirs.html#optimizer_plan" alt="plan" /> |
||||
<area coords="45, 525, 175, 555" href="backend_dirs.html#executor" alt="executor" /> |
||||
<area coords="0, 640, 130, 675" href="backend_dirs.html#utils" alt="utils" /> |
||||
<area coords="175, 640, 300, 675" href="backend_dirs.html#catalog" alt="catalog" /> |
||||
<area coords="330, 640, 475, 675" href="backend_dirs.html#storage" alt="storage" /> |
||||
<area coords="75, 700, 210, 735" href="backend_dirs.html#access" alt="access" /> |
||||
<area coords="255, 705, 380, 735" href="backend_dirs.html#nodes" alt="nodes" /> |
||||
</map> |
||||
</center> |
||||
|
||||
<br /> |
||||
|
||||
<p>A query comes to the backend via data packets arriving through |
||||
TCP/IP or Unix Domain sockets. It is loaded into a string, and |
||||
passed to the <a href="../../backend/parser">parser,</a> where the |
||||
lexical scanner, <a href="../../backend/parser/scan.l">scan.l,</a> |
||||
breaks the query up into tokens(words). The parser uses <a |
||||
href="../../backend/parser/gram.y">gram.y</a> and the tokens to |
||||
identify the query type, and load the proper query-specific |
||||
structure, like <a |
||||
href="../../include/nodes/parsenodes.h">CreateStmt</a> or <a |
||||
href="../../include/nodes/parsenodes.h">SelectStmt.</a></p> |
||||
|
||||
<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. 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 |
||||
contains all the elements used by complex queries. Query.qual holds |
||||
the <i>WHERE</i> clause qualification, which is filled in by <a |
||||
href="../../backend/parser/parse_clause.c">transformWhereClause().</a> |
||||
Each table referenced in the query is represented by a <a |
||||
href="../../include/nodes/parsenodes.h">RangeTableEntry,</a> and |
||||
they are linked together to form the <i>range table</i> of the |
||||
query, which is generated by <a |
||||
href="../../backend/parser/parse_clause.c">transformFromClause().</a> |
||||
Query.rtable holds the query's range table.</p> |
||||
|
||||
<p>Certain queries, like <i>SELECT,</i> return columns of data. |
||||
Other queries, like <i>INSERT</i> and <i>UPDATE,</i> specify the |
||||
columns modified by the query. These column references are |
||||
converted to <a |
||||
href="../../include/nodes/primnodes.h">TargetEntry</a> entries, |
||||
which are linked together to make up the <i>target list</i> of the |
||||
query. The target list is stored in Query.targetList, which is |
||||
generated by <a |
||||
href="../../backend/parser/parse_target.c">transformTargetList().</a></p> |
||||
|
||||
<p>Other query elements, like aggregates(<i>SUM()</i>), <i>GROUP |
||||
BY,</i> and <i>ORDER BY</i> are also stored in their own Query |
||||
fields.</p> |
||||
|
||||
<p>The next step is for the Query to be modified by any |
||||
<i>VIEWS</i> or <i>RULES</i> that may apply to the query. This is |
||||
performed by the <a href="../../backend/rewrite">rewrite</a> |
||||
system.</p> |
||||
|
||||
<p>The <a href="../../backend/optimizer">optimizer</a> takes the |
||||
Query structure and generates an optimal <a |
||||
href="../../include/nodes/plannodes.h">Plan,</a> which contains the |
||||
operations to be performed to execute the query. The <a |
||||
href="../../backend/optimizer/path">path</a> module determines the |
||||
best table join order and join type of each table in the |
||||
RangeTable, using Query.qual(<i>WHERE</i> clause) to consider |
||||
optimal index usage.</p> |
||||
|
||||
<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 is actually as set of nodes, |
||||
arranged in a tree structure with a top-level node, and various |
||||
sub-nodes as children.</p> |
||||
|
||||
<p>There are many other modules that support this basic |
||||
functionality. They can be accessed by clicking on the |
||||
flowchart.</p> |
||||
|
||||
<hr /> |
||||
<p>Another area of interest is the shared memory area, which |
||||
contains data accessible to all backends. It has recently used |
||||
data/index blocks, locks, backend process information, and lookup |
||||
tables for these structures:</p> |
||||
|
||||
<ul> |
||||
<li>ShmemIndex - lookup shared memory addresses using structure |
||||
names</li> |
||||
|
||||
<li><a href="../../include/storage/buf_internals.h">Buffer |
||||
Descriptor</a> - control header for buffer cache block</li> |
||||
|
||||
<li><a href="../../include/storage/buf_internals.h">Buffer |
||||
Block</a> - data/index buffer cache block</li> |
||||
|
||||
<li>Shared Buffer Lookup Table - lookup of buffer cache block |
||||
addresses using table name and block number( <a |
||||
href="../../include/storage/buf_internals.h">BufferTag</a>)</li> |
||||
|
||||
<li>Lock Manager Tables (lock hash) - the <a |
||||
href="../../include/storage/lock.h">LOCK</a> structure, looked up |
||||
using a <a href="../../include/storage/lock.h">LOCKTAG</a>. |
||||
A LOCK structure exists for each lockable object that is currently |
||||
locked by any backend. Also, there is a subsidiary <a |
||||
href="../../include/storage/lock.h">PROCLOCK</a> structure for each |
||||
backend currently interested in a given LOCK</li> |
||||
|
||||
<li><a href="../../include/storage/proc.h">PGPROC Structures</a> - |
||||
information about each backend, including locks held/waiting</li> |
||||
</ul> |
||||
|
||||
<p>Each data structure is created by calling <a |
||||
href="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</a> and |
||||
the lookups are created by <a |
||||
href="../../backend/storage/ipc/shmem.c">ShmemInitHash().</a></p> |
||||
|
||||
<hr /> |
||||
<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> |
||||
Loading…
Reference in new issue