diff options
| -rw-r--r-- | src/tools/backend/backend_dirs.html | 73 | ||||
| -rw-r--r-- | src/tools/backend/index.html | 94 |
2 files changed, 80 insertions, 87 deletions
diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html index cc4e16d9aa2..433324bff13 100644 --- a/src/tools/backend/backend_dirs.html +++ b/src/tools/backend/backend_dirs.html @@ -3,18 +3,17 @@ <TITLE>PostgreSQL Backend Directories</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF"> -<H1 ALIGN=CENTER> +<H1> PostgreSQL Backend Directories </H1> -<H2 ALIGN=CENTER> +<H2> by Bruce Momjian </H2> -<P> -<P> <HR> +<P> <EM>Click on any of the section headings to see the source code for that section. </EM> -<P> +</P> <H2> <A NAME="bootstrap"></A> <A HREF="../../backend/bootstrap">bootstrap</A> @@ -94,7 +93,7 @@ This uses the parser output to generate an optimal plan for the executor. </P> <H3> -<A NAME="optimizer/path"></A> +<A NAME="optimizer_path"></A> <A HREF="../../backend/optimizer/path">optimizer/path</A> - creates path from parser output </H3> @@ -106,7 +105,7 @@ and optimizer table statistics to evaluate each possible execution method, and assigns a cost to each. </P> <H3> -<A NAME="optimizer/geqo"></A> +<A NAME="optimizer_geqo"></A> <A HREF="../../backend/optimizer/geqo">optimizer/geqo</A> - genetic query optimizer </H3> @@ -121,7 +120,7 @@ tables, it is faster. There is an option to control when this feature is used. </P> <H3> -<A NAME="optimizer/plan"></A> +<A NAME="optimizer_plan"></A> <A HREF="../../backend/optimizer/plan">optimizer/plan</A> - optimizes path output </H3> @@ -130,7 +129,7 @@ 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 NAME="optimizer_prep"></A> <A HREF="../../backend/optimizer/prep">optimizer/prep</A> - handle special plan cases </H3> @@ -138,7 +137,7 @@ least cost, and creates a plan for the executor. This does special plan processing. </P> <H3> -<A NAME="optimizer/util"></A> +<A NAME="optimizer_util"></A> <A HREF="../../backend/optimizer/util">optimizer/util</A> - optimizer support routines </H3> @@ -190,31 +189,31 @@ that pre-format user requests into a predefined format. These allow uniform resource access by the backend. <BR> <BR> -<A NAME="storage/buffer"></A> +<A NAME="storage_buffer"></A> <A HREF="../../backend/storage/buffer">storage/buffer</A> - shared buffer pool manager <BR> -<A NAME="storage/file"></A> +<A NAME="storage_file"></A> <A HREF="../../backend/storage/file">storage/file</A> - file manager <BR> -<A NAME="storage/ipc"></A> +<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 NAME="storage_large_object"></A> <A HREF="../../backend/storage/large_object">storage/large_object</A> - large objects <BR> -<A NAME="storage/lmgr"></A> +<A NAME="storage_lmgr"></A> <A HREF="../../backend/storage/lmgr">storage/lmgr</A> - lock manager <BR> -<A NAME="storage/page"></A> +<A NAME="storage_page"></A> <A HREF="../../backend/storage/page">storage/page</A> - page manager <BR> -<A NAME="storage/smgr"></A> +<A NAME="storage_smgr"></A> <A HREF="../../backend/storage/smgr">storage/smgr</A> - storage/disk manager <BR> @@ -230,35 +229,35 @@ These control the way data is accessed in heap, indexes, and transactions. <BR> <BR> -<A NAME="access/common"></A> +<A NAME="access_common"></A> <A HREF="../../backend/access/common">access/common</A> - common access routines <BR> -<A NAME="access/gist"></A> +<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 NAME="access_hash"></A> <A HREF="../../backend/access/hash">access/hash</A> - hash <BR> -<A NAME="access/heap"></A> +<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 NAME="access_index"></A> <A HREF="../../backend/access/index">access/index</A> - used by all index types <BR> -<A NAME="access/nbtree"></A> +<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 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 NAME="access_transam"></A> <A HREF="../../backend/access/transam">access/transam</A> - transaction manager (BEGIN/ABORT/COMMIT) <BR> @@ -289,7 +288,7 @@ store requests and data. - support routines </H2> <H3> -<A NAME="utils/adt"></A> +<A NAME="utils_adt"></A> <A HREF="../../backend/utils/adt">utils/adt</A> - built-in data type routines </H3> @@ -297,7 +296,7 @@ store requests and data. This contains all the PostgreSQL builtin data types. </P> <H3> -<A NAME="utils/cache"></A> +<A NAME="utils_cache"></A> <A HREF="../../backend/utils/cache">utils/cache</A> - system/relation/function cache routines </H3> @@ -314,7 +313,7 @@ This last cache maintains information about all recently-accessed tables, not just system ones. </P> <H3> -<A NAME="utils/error"></A> +<A NAME="utils_error"></A> <A HREF="../../backend/utils/error">utils/error</A> - error reporting routines </H3> @@ -322,7 +321,7 @@ tables, not just system ones. Reports backend errors to the front end. </P> <H3> -<A NAME="utils/fmgr"></A> +<A NAME="utils_fmgr"></A> <A HREF="../../backend/utils/fmgr">utils/fmgr</A> - function manager </H3> @@ -331,7 +330,7 @@ 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 NAME="utils_hash"></A> <A HREF="../../backend/utils/hash">utils/hash</A> - hash routines for internal algorithms </H3> @@ -341,17 +340,17 @@ do quick lookups of dynamic data storage structures maintained by the backend. </P> <H3> -<A NAME="utils/init"></A> +<A NAME="utils_init"></A> <A HREF="../../backend/utils/init">utils/init</A> - various initialization stuff </H3> <H3> -<A NAME="utils/misc"></A> +<A NAME="utils_misc"></A> <A HREF="../../backend/utils/misc">utils/misc</A> - miscellaneous stuff </H3> <H3> -<A NAME="utils/mmgr"></A> +<A NAME="utils_mmgr"></A> <A HREF="../../backend/utils/mmgr">utils/mmgr</A> - memory manager(process-local memory) </H3> @@ -363,7 +362,7 @@ By doing this, the backend can easily free memory once a statement or transaction completes. </P> <H3> -<A NAME="utils/sort"></A> +<A NAME="utils_sort"></A> <A HREF="../../backend/utils/sort">utils/sort</A> - sort routines for internal algorithms </H3> @@ -372,7 +371,7 @@ 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 NAME="utils_time"></A> <A HREF="../../backend/utils/time">utils/time</A> - transaction time qualification routines </H3> @@ -419,13 +418,11 @@ This does processing for the rules system. - unused (array handling?) </H2> <BR> -<HR SIZE="2" NOSHADE> +<HR> <SMALL> -<ADDRESS> 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 -</ADDRESS> </SMALL> </BODY> </HTML> diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index 78b8b8e5fac..241c4bb5d57 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -3,42 +3,40 @@ <TITLE>How PostgreSQL Processes a Query</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF"> -<H1 ALIGN=CENTER> +<H1> How PostgreSQL Processes a Query </H1> -<H2 ALIGN=CENTER> +<H2> by Bruce Momjian </H2> <P> -<CENTER> -<IMG src="flow.gif" usemap="#flowmap" alt="flowchart" border=0> -</CENTER> -<MAP name="flowmap"> -<AREA COORDS="125,35,245,65" HREF="backend_dirs.html#main"> -<AREA COORDS="125,100,245,125" HREF="backend_dirs.html#postmaster"> -<AREA COORDS="325,65,450,95" HREF="backend_dirs.html#libpq"> -<AREA COORDS="125,160,245,190" HREF="backend_dirs.html#tcop"> -<AREA COORDS="325,160,450,190" HREF="backend_dirs.html#tcop"> -<AREA COORDS="125,240,245,265" HREF="backend_dirs.html#parser"> -<AREA COORDS="125,300,250,330" HREF="backend_dirs.html#tcop"> -<AREA COORDS="125,360,250,390" HREF="backend_dirs.html#optimizer"> -<AREA COORDS="125,425,245,455" HREF="backend_dirs.html#optimizer/plan"> -<AREA COORDS="125,490,245,515" HREF="backend_dirs.html#executor"> -<AREA COORDS="325,300,450,330" HREF="backend_dirs.html#commands"> -<AREA COORDS="75,575,195,605" HREF="backend_dirs.html#utils"> -<AREA COORDS="235,575,360,605" HREF="backend_dirs.html#catalog"> -<AREA COORDS="405,575,525,605" HREF="backend_dirs.html#storage"> -<AREA COORDS="155,635,275,665" HREF="backend_dirs.html#access"> -<AREA COORDS="325,635,450,665" HREF="backend_dirs.html#nodes"> -<AREA COORDS="75,705,200,730" HREF="backend_dirs.html#bootstrap"> +<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"></AREA> +<AREA coords="125,100,245,125" HREF="backend_dirs.html#postmaster" alt="postmaster"></AREA> +<AREA coords="325,65,450,95" HREF="backend_dirs.html#libpq" alt="libpq"></AREA> +<AREA coords="125,160,245,190" HREF="backend_dirs.html#tcop" alt="tcop"></AREA> +<AREA coords="325,160,450,190" HREF="backend_dirs.html#tcop" alt="tcop"></AREA> +<AREA coords="125,240,245,265" HREF="backend_dirs.html#parser" alt="parser"></AREA> +<AREA coords="125,300,250,330" HREF="backend_dirs.html#tcop" alt="tcop"></AREA> +<AREA coords="125,360,250,390" HREF="backend_dirs.html#optimizer" alt="optimizer"></AREA> +<AREA coords="125,425,245,455" HREF="backend_dirs.html#optimizer_plan" alt="plan"></AREA> +<AREA coords="125,490,245,515" HREF="backend_dirs.html#executor" alt="executor"></AREA> +<AREA coords="325,300,450,330" HREF="backend_dirs.html#commands" alt="commands"></AREA> +<AREA coords="75,575,195,605" HREF="backend_dirs.html#utils" alt="utils"></AREA> +<AREA coords="235,575,360,605" HREF="backend_dirs.html#catalog" alt="catalog"></AREA> +<AREA coords="405,575,525,605" HREF="backend_dirs.html#storage" alt="storage"></AREA> +<AREA coords="155,635,275,665" HREF="backend_dirs.html#access" alt="access"></AREA> +<AREA coords="325,635,450,665" HREF="backend_dirs.html#nodes" alt="nodes"></AREA> +<AREA coords="75,705,200,730" HREF="backend_dirs.html#bootstrap" alt="bootstrap"></AREA> </MAP> -<CENTER><EM> +<EM> Click on an item to see more detail or look at the full <A HREF="backend_dirs.html">index.</A> -</EM></CENTER> +</EM> <BR> <BR> - +</P> <P> A query comes to the backend via data packets arriving through TCP/IP or @@ -49,13 +47,13 @@ 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> +HREF="../../include/nodes/parsenodes.h">SelectStmt.</A></P><P> The query is then identified as a <I>Utility</I> query or a more complex query. A <I>Utility</I> query is processed by a query-specific function in <A HREF="../../backend/commands"> commands.</A> A complex query, like -<I>SELECT, UPDATE,</I> and <I>DELETE</I> requires much more handling.<P> +<I>SELECT, UPDATE,</I> and <I>DELETE</I> requires much more handling.</P><P> The parser takes a complex query, and creates a @@ -67,7 +65,7 @@ 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> +transformFromClause().</A> Query.rtable holds the query's range table.</P><P> Certain queries, like <I>SELECT,</I> return columns of data. Other @@ -78,16 +76,16 @@ placed in <A HREF="../../include/nodes/parsenodes.h">target list entries,</A> and 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> +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> +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> +HREF="../../backend/rewrite">rewrite</A> system.</P><P> The <A HREF="../../backend/optimizer">optimizer</A> takes the Query @@ -96,18 +94,17 @@ 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> +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 actually as set of nodes, arranged in a tree structure with a top-level node, and various sub-nodes as -children.<P> - +children.</P><P> There are many other modules that support this basic functionality. They -can be accessed by clicking on the flowchart.<P> +can be accessed by clicking on the flowchart.</P> <HR><P> @@ -117,19 +114,20 @@ Another area of interest is the shared memory area, which contains data accessable 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>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 +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 +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>) +HREF="../../include/storage/buf_internals.h"> BufferTag</A>)</LI> <LI>MultiLevelLockTable (ctl) - control structure for each locking method. Currently, only multi-level locking is used(<A -HREF="../../include/storage/lock.h">LOCKMETHODCTL</A>). +HREF="../../include/storage/lock.h">LOCKMETHODCTL</A>).</LI> <LI>MultiLevelLockTable (lock hash) - the <A HREF="../../include/storage/lock.h">LOCK</A> structure, looked up using relation, database object ids(<A @@ -137,31 +135,29 @@ HREF="../../include/storage/lock.h">LOCKTAG)</A>. The lock table structure contains the lock modes(read/write or shared/exclusive) and circular linked list of backends (<A HREF="../../include/storage/proc.h">PROC</A> structure pointers) waiting -on the lock. +on the lock.</LI> <LI>MultiLevelLockTable (xid hash) - lookup of LOCK structure address using transaction id, LOCK address. It is used to quickly check if the current transaction already has any locks on a table, rather than having to search through all the held locks. It also stores the modes (read/write) of the locks held by the current transaction. The returned <A HREF="../../include/storage/lock.h">XIDLookupEnt</A> structure also -contains a pointer to the backend's PROC.lockQueue. +contains a pointer to the backend's PROC.lockQueue.</LI> <LI><A HREF="../../include/storage/proc.h">Proc Header</A> - information -about each backend, including locks held/waiting, indexed by process id +about each backend, including locks held/waiting, indexed by process id</LI> </UL> -Each data structure is created by calling <A +<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> +HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A></P> -<HR SIZE="2" NOSHADE> +<HR> <SMALL> -<ADDRESS> Maintainer: Bruce Momjian (<A HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR> Last updated: Mon Aug 10 10:48:06 EDT 1998 -</ADDRESS> </SMALL> </BODY> </HTML> |