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

Update backend flowchart.

Browse Source
REL6_4
Bruce Momjian 28 years ago
parent 54aabaa800
commit 0cba552301
3 changed files with 233 additions and 140 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. 4
      src/backend/storage/ipc/shmem.c
  2. 272
      src/tools/backend/backend_dirs.html
  3. 97
      src/tools/backend/index.html

4
src/backend/storage/ipc/shmem.c
Unescape View File

@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.25 1998/06/27 15:47:44 momjian Exp $
* $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.26 1998/06/28 06:17:13 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -487,7 +487,7 @@ ShmemInitStruct(char *name, unsigned long size, bool *foundPtr)
item.location = BAD_LOCATION;
SpinAcquire(ShmemIndexLock);
if (!ShmemIndex)
{
#ifdef USE_ASSERT_CHECKING

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

@ -8,15 +8,16 @@ PostgreSQL Backend Directories
</H1>
<H2 ALIGN=CENTER>
by Bruce Momjian
</H2 ALIGN=CENTER>
</H2>
<P>
<P>
<HR>
<EM>Click on any of the section headings to see the source code for that section.
</EM>
<P>
<H2>
<A NAME="bootstrap">
<A HREF="../../backend/bootstrap">bootstrap</A></A>
<A NAME="bootstrap"></A>
<A HREF="../../backend/bootstrap">bootstrap</A>
- creates initial template database via initdb
</H2>
<P>
@ -29,8 +30,8 @@ This code <I>jams</I> the data directly into tables using a
special syntax used only by the bootstrap procedure.
</P>
<H2>
<A NAME="main">
<A HREF="../../backend/main">main</A></A>
<A NAME="main"></A>
<A HREF="../../backend/main">main</A>
- passes control to postmaster or postgres
</H2>
<P>
@ -38,8 +39,8 @@ This checks the process name(argv[0]) and various flags, and passes
control to the postmaster or postgres backend code.
</P>
<H2>
<A NAME="postmaster">
<A HREF="../../backend/postmaster">postmaster</A></A>
<A NAME="postmaster"></A>
<A HREF="../../backend/postmaster">postmaster</A>
- controls postgres server startup/termination
</H2>
<P>
@ -49,16 +50,16 @@ When a connection request arrives, a <I>postgres</I> backend is started,
and the connection is passed to it.
</P>
<H2>
<A NAME="libpq">
<A HREF="../../backend/libpq">libpq</A></A>
<A 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 NAME="tcop">
<A HREF="../../backend/tcop">tcop</A></A>
<A NAME="tcop"></A>
<A HREF="../../backend/tcop">tcop</A>
- traffic cop, dispatches request to proper module
</H2>
<P>
@ -67,8 +68,8 @@ code that makes calls to the parser, optimizer, executor, and
<I>/commands</I> functions.
</P>
<H2>
<A NAME="parser">
<A HREF="../../backend/parser">parser</A></A>
<A NAME="parser"></A>
<A HREF="../../backend/parser">parser</A>
- converts SQL query to query tree
</H2>
<P>
@ -84,19 +85,19 @@ The command-specific structures are then broken apart, checked, and passed to
<I>Nodes</I> to be handled by the optimizer and executor.
</P>
<H2>
<A NAME="optimizer">
<A HREF="../../backend/optimizer">optimizer</A></A>
<A 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>
<H4>
<A NAME="optimizer/path">
<A HREF="../../backend/optimizer/path">optimizer/path</A></A>
<H3>
<A NAME="optimizer/path"></A>
<A HREF="../../backend/optimizer/path">optimizer/path</A>
- creates path from parser output
</H4>
</H3>
<P>
This takes the parser query output, and generates all possible methods of
executing the request.
@ -104,11 +105,11 @@ 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>
<H4>
<A NAME="optimizer/geqo">
<A HREF="../../backend/optimizer/geqo">optimizer/geqo</A></A>
<H3>
<A NAME="optimizer/geqo"></A>
<A HREF="../../backend/optimizer/geqo">optimizer/geqo</A>
- genetic query optimizer
</H4>
</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
@ -119,34 +120,34 @@ 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>
<H4>
<A NAME="optimizer/plan">
<A HREF="../../backend/optimizer/plan">optimizer/plan</A></A>
<H3>
<A NAME="optimizer/plan"></A>
<A HREF="../../backend/optimizer/plan">optimizer/plan</A>
- optimizes path output
</H4>
</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>
<H4>
<A NAME="optimizer/prep">
<A HREF="../../backend/optimizer/prep">optimizer/prep</A></A>
<H3>
<A NAME="optimizer/prep"></A>
<A HREF="../../backend/optimizer/prep">optimizer/prep</A>
- handle special plan cases
</H4>
</H3>
<P>
This does special plan processing.
</P>
<H4>
<A NAME="optimizer/util">
<A HREF="../../backend/optimizer/util">optimizer/util</A></A>
<H3>
<A NAME="optimizer/util"></A>
<A HREF="../../backend/optimizer/util">optimizer/util</A>
- optimizer support routines
</H4>
</H3>
<P>
This contains support routines used by other parts of the optimizer.
</P>
<H2>
<A NAME="executor">
<A HREF="../../backend/executor">executor</A></A>
<A NAME="executor"></A>
<A HREF="../../backend/executor">executor</A>
- executes complex node plans from optimizer
</H2>
<P>
@ -156,8 +157,8 @@ heap scans, index scans, sorting, joining tables, grouping, aggregates,
and uniqueness.
</P>
<H2>
<A NAME="commands">
<A HREF="../../backend/commands">commands</A></A>
<A NAME="commands"></A>
<A HREF="../../backend/commands">commands</A>
- commands that do not require the executor
</H2>
<P>
@ -169,8 +170,8 @@ Most of the routines do some processing, then call lower-level functions
in the catalog directory to do the actual work.
</P>
<H2>
<A NAME="catalog">
<A HREF="../../backend/catalog">catalog</A></A>
<A NAME="catalog"></A>
<A HREF="../../backend/catalog">catalog</A>
- system catalog manipulation
</H2>
<P>
@ -181,47 +182,47 @@ These are low-level routines, and are usually called by upper routines
that pre-format user requests into a predefined format.
</P>
<H2>
<A NAME="storage">
<A HREF="../../backend/storage">storage</A></A>
<A 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 NAME="storage/buffer">
<A HREF="../../backend/storage/buffer">storage/buffer</A></A>
<A NAME="storage/buffer"></A>
<A HREF="../../backend/storage/buffer">storage/buffer</A>
- shared buffer pool manager
<BR>
<A NAME="storage/file">
<A HREF="../../backend/storage/file">storage/file</A></A>
<A NAME="storage/file"></A>
<A HREF="../../backend/storage/file">storage/file</A>
- file manager
<BR>
<A NAME="storage/ipc">
<A HREF="../../backend/storage/ipc">storage/ipc</A></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 HREF="../../backend/storage/large_object">storage/large_object</A></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 HREF="../../backend/storage/lmgr">storage/lmgr</A></A>
<A NAME="storage/lmgr"></A>
<A HREF="../../backend/storage/lmgr">storage/lmgr</A>
- lock manager
<BR>
<A NAME="storage/page">
<A HREF="../../backend/storage/page">storage/page</A></A>
<A NAME="storage/page"></A>
<A HREF="../../backend/storage/page">storage/page</A>
- page manager
<BR>
<A NAME="storage/smgr">
<A HREF="../../backend/storage/smgr">storage/smgr</A></A>
<A NAME="storage/smgr"></A>
<A HREF="../../backend/storage/smgr">storage/smgr</A>
- storage/disk manager
<BR>
<BR>
</P>
<H2>
<A NAME="access">
<A HREF="../../backend/access">access</A></A>
<A NAME="access"></A>
<A HREF="../../backend/access">access</A>
- various data access methods
</H2>
<P>
@ -229,43 +230,43 @@ These control the way data is accessed in heap, indexes, and
transactions.
<BR>
<BR>
<A NAME="access/common">
<A HREF="../../backend/access/common">access/common</A></A>
<A NAME="access/common"></A>
<A HREF="../../backend/access/common">access/common</A>
- common access routines
<BR>
<A NAME="access/gist">
<A HREF="../../backend/access/gist">access/gist</A></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 HREF="../../backend/access/hash">access/hash</A></A>
<A NAME="access/hash"></A>
<A HREF="../../backend/access/hash">access/hash</A>
- hash
<BR>
<A NAME="access/heap">
<A HREF="../../backend/access/heap">access/heap</A></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 HREF="../../backend/access/index">access/index</A></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 HREF="../../backend/access/nbtree">access/nbtree</A></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 HREF="../../backend/access/rtree">access/rtree</A></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 HREF="../../backend/access/transam">access/transam</A></A>
<A NAME="access/transam"></A>
<A HREF="../../backend/access/transam">access/transam</A>
- transaction manager (BEGIN/ABORT/COMMIT)
<BR>
<BR>
</P>
<H2>
<A NAME="nodes">
<A HREF="../../backend/nodes">nodes</A></A>
<A NAME="nodes"></A>
<A HREF="../../backend/nodes">nodes</A>
- creation/manipulation of nodes and lists
</H2>
<P>
@ -283,23 +284,23 @@ These are used extensively in the parser, optimizer, and executor to
store requests and data.
</P>
<H2>
<A NAME="utils">
<A HREF="../../backend/utils">utils</A></A>
<A NAME="utils"></A>
<A HREF="../../backend/utils">utils</A>
- support routines
</H2>
<H4>
<A NAME="utils/adt">
<A HREF="../../backend/utils/adt">utils/adt</A></A>
<H3>
<A NAME="utils/adt"></A>
<A HREF="../../backend/utils/adt">utils/adt</A>
- built-in data type routines
</H4>
</H3>
<P>
This contains all the PostgreSQL builtin data types.
</P>
<H4>
<A NAME="utils/cache">
<A HREF="../../backend/utils/cache">utils/cache</A></A>
<H3>
<A NAME="utils/cache"></A>
<A HREF="../../backend/utils/cache">utils/cache</A>
- system/relation/function cache routines
</H4>
</H3>
<P>
PostgreSQL supports arbitrary data types, so no data types are hard-coded
into the core backend routines.
@ -312,48 +313,48 @@ information cache.
This last cache maintains information about all recently-accessed
tables, not just system ones.
</P>
<H4>
<A NAME="utils/error">
<A HREF="../../backend/utils/error">utils/error</A></A>
<H3>
<A NAME="utils/error"></A>
<A HREF="../../backend/utils/error">utils/error</A>
- error reporting routines
</H4>
</H3>
<P>
Reports backend errors to the front end.
</P>
<H4>
<A NAME="utils/fmgr">
<A HREF="../../backend/utils/fmgr">utils/fmgr</A></A>
<H3>
<A NAME="utils/fmgr"></A>
<A HREF="../../backend/utils/fmgr">utils/fmgr</A>
- function manager
</H4>
</H3>
<P>
This handles the calling of dynamically-loaded functions, and the calling
of functions defined in the system tables.
</P>
<H4>
<A NAME="utils/hash">
<A HREF="../../backend/utils/hash">utils/hash</A></A>
<H3>
<A NAME="utils/hash"></A>
<A HREF="../../backend/utils/hash">utils/hash</A>
- hash routines for internal algorithms
</H4>
</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>
<H4>
<A NAME="utils/init">
<A HREF="../../backend/utils/init">utils/init</A></A>
<H3>
<A NAME="utils/init"></A>
<A HREF="../../backend/utils/init">utils/init</A>
- various initialization stuff
</H4>
<H4>
<A NAME="utils/misc">
<A HREF="../../backend/utils/misc">utils/misc</A></A>
</H3>
<H3>
<A NAME="utils/misc"></A>
<A HREF="../../backend/utils/misc">utils/misc</A>
- miscellaneous stuff
</H4>
<H4>
<A NAME="utils/mmgr">
<A HREF="../../backend/utils/mmgr">utils/mmgr</A></A>
</H3>
<H3>
<A NAME="utils/mmgr"></A>
<A HREF="../../backend/utils/mmgr">utils/mmgr</A>
- memory manager(process-local memory)
</H4>
</H3>
<P>
When PostgreSQL allocates memory, it does so in an explicit context.
Contexts can be statement-specific, transaction-specific, or
@ -361,65 +362,70 @@ persistent/global.
By doing this, the backend can easily free memory once a statement or
transaction completes.
</P>
<H4>
<A NAME="utils/sort">
<A HREF="../../backend/utils/sort">utils/sort</A></A>
<H3>
<A NAME="utils/sort"></A>
<A HREF="../../backend/utils/sort">utils/sort</A>
- sort routines for internal algorithms
</H4>
</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>
<H4>
<A NAME="utils/time">
<A HREF="../../backend/utils/time">utils/time</A></A>
<H3>
<A NAME="utils/time"></A>
<A HREF="../../backend/utils/time">utils/time</A>
- transaction time qualification routines
</H4>
</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 NAME="include">
<A HREF="../../backend/include">include</A></A>
<A NAME="include"></A>
<A HREF="../../backend/include">include</A>
- include files
</H2>
<P>
There are include directories for each subsystem.
</P>
<H2>
<A NAME="lib">
<A HREF="../../backend/lib">lib</A></A>
<A NAME="lib"></A>
<A HREF="../../backend/lib">lib</A>
- support library
</H2>
<P>
This houses several generic routines.
</P>
<H2>
<A NAME="regex">
<A HREF="../../backend/regex">regex</A></A>
<A 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 NAME="rewrite">
<A HREF="../../backend/rewrite">rewrite</A></A>
<A NAME="rewrite"></A>
<A HREF="../../backend/rewrite">rewrite</A>
- rules system
</H2>
<P>
This does processing for the rules system.
</P>
<H2>
<A NAME="tioga">
<A HREF="../../backend/tioga">tioga</A></A>
<A NAME="tioga"></A>
<A HREF="../../backend/tioga">tioga</A>
- unused (array handling?)
</H2>
<HR>
<BR>
<HR SIZE="2" NOSHADE>
<SMALL>
<ADDRESS>
Maintainer: Bruce Momjian<A
HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</a>)<BR>
Last updated: Mon Oct 27 11:01:08 EST 1997
Maintainer: Bruce Momjian (<A
HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</A>)<BR>
Last updated: Tue Dec 9 17:56:08 EST 1997
</ADDRESS>
</SMALL>
</BODY>
</HTML>

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

@ -9,8 +9,90 @@ PostgreSQL Backend Flowchart
<H2 ALIGN=CENTER>
by Bruce Momjian
</H2 ALIGN=CENTER>
<P>
Queries come into the backend via data packets coming in through TCP/IP
and Unix Domain sockets. They are 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-type-specific
structure, like
<A HREF="../../include/nodes/parsenodes.h">CreateStmt or SelectStmt.</A>
<P>
The query is then identified as a <I>Utility</I> function or a more
complex query. <I>Utility</I> queries are processed by a
query-type-specific function in <A HREF="../../backend/commands">
commands.</A> Complex queries, like <I>SELECT, UPDATE,</I> and
<I>DELETE</I> require much more handling.
<P>
The parser takes the complex queries, 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
WHERE clause qualification, which is filled in by
<A HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A>
Each table is represented by a <A HREF="../../include/nodes/parsenodes.h">
RangeTableEntry,</A>
and they are linked together to form the <I>range table</I> for the
query, and is generated by <A HREF="../../backend/parser/parse_clause.c">
makeRangeTable().</A> Query.rtable holds the queries range table.
<P>
Certain queries, like SELECT, return columns of data. Other queries,
like INSERT and UPDATE, specify the columns modified by the query.
These columns references are converted to <A
HREF="../../include/nodes/primnodes.h"> Resdom</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, and is generated by
<A HREF="../../backend/parser/parse_target.c">transformTargetList().</A>
<P>
Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are
also stored in their own fields.
<P>
The next step is for the Query to be modified by any VIEWS or RULES that
may apply to the query. This is performed by the <A
HREF="../../backend/rewrite">rewrite</A> system.
<P>
The optimizer takes the Query structure, and generates an optimal
<A HREF="../..//include/nodes/plannodes.h">Plan</A> containing primitive
operations to be performed by the executor to complete the query. The
<A HREF="../../backend/optimizer/path">path</A> module
determines the table join order and join type of each of the tables in
the RangeTable, using Query.qual(WHERE clause) to consider optimal index
usage.
<P>
The Plan is then passed to the <A
HREF="../../backend/executor">executor</A> for execution, and the result
is returned to the client.
<P>
There are many other modules that support this basic functionality.
They can be accessed by clicking on the flowchart.
<P>
Another area of interest is the shared memory area, containing
table data/index blocks, locks, and backend information:
<UL>
<LI>ShmemIndex - contains an index of all other shared memory
structures, allowing quick lookup of other structure locations in shared
memory
<LI>Buffer Descriptors - control header for shared memory buffer block
<LI>Buffer Blocks - block of table/index data shared by all backends
<LI>Shared Buf Lookup Table - lookup to see if a requested buffer
is already in the shared memory area
<LI>LockTable - lock table structure, specifiying table, lock types, and
backends holding or waiting on lock
<LI>LockTable (lock hash) - lookup of LockTable structures using
table name
<LI>LockTable (xid hash) - lookup of LockTable structures using
transaction id
<LI>Proc Header - information about each backend, including locks held/waiting,
indexed by process id
</UL>
Each structure is created by calling <A
HREF="../../backend/storage/ipc/shmem.c"> ShmemInitStruct().</A>
<HR>
<CENTER>
<BR>
<EM><BIG>
Click on an item to see more detail or click
<A HREF="backend_dirs.html">here</a> to see the full index.
@ -38,9 +120,14 @@ Click on an item to see more detail or click
<AREA COORDS="10,510,170,550" HREF="backend_dirs.html#nodes">
<AREA COORDS="10,570,170,610" HREF="backend_dirs.html#storage">
</MAP>
<HR>
<BR>
<HR SIZE="2" NOSHADE>
<SMALL>
<ADDRESS>
Maintainer: Bruce Momjian<A
HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</a>)<BR>
Last updated: Mon Oct 27 11:01:08 EST 1997
Maintainer: Bruce Momjian (<A
HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</A>)<BR>
Last updated: Tue Dec 9 17:56:08 EST 1997
</ADDRESS>
</SMALL>
</BODY>
</HTML>

Write Preview
Loading…
Cancel
Save