src/tools/backend/backend_dirs.html - hawq - Git at Google

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