| <!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> |