open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Attached patch cleans up the HTML code in tools/backend. This is

Browse Source 
required for us to pull it into the main website. Same kind of fixes as
last time, just make sure things aren't violating the HTML standard. No
context changes at all.

Magnus Hagander
REL8_1_STABLE
Bruce Momjian 21 years ago
parent e6557e9a67
commit 0f3748a28c
2 changed files with 80 additions and 87 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 73
      src/tools/backend/backend_dirs.html
  2. 94
      src/tools/backend/index.html

73
src/tools/backend/backend_dirs.html
Unescape View File

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

94
src/tools/backend/index.html
Unescape View File

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

Write Preview
Loading…
Cancel
Save