From: Bruce Momjian Date: Wed, 6 Apr 2005 15:19:03 +0000 (+0000) Subject: Attached patch cleans up the HTML code in tools/backend. This is X-Git-Tag: REL9_0_0~10455 X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=0f3748a28c42d09d794ff00af3f1f992eaa5fd7c;p=pg-rex%2Fsyncrep.git Attached patch cleans up the HTML code in tools/backend. This is 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 --- diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html index cc4e16d9aa..433324bff1 100644 --- a/src/tools/backend/backend_dirs.html +++ b/src/tools/backend/backend_dirs.html @@ -3,18 +3,17 @@ PostgreSQL Backend Directories -

+

PostgreSQL Backend Directories

-

+

by Bruce Momjian

-

-

+

Click on any of the section headings to see the source code for that section. -

+

bootstrap @@ -94,7 +93,7 @@ This uses the parser output to generate an optimal plan for the executor.

- + optimizer/path - creates path from parser output

@@ -106,7 +105,7 @@ and optimizer table statistics to evaluate each possible execution method, and assigns a cost to each.

- + optimizer/geqo - genetic query optimizer

@@ -121,7 +120,7 @@ tables, it is faster. There is an option to control when this feature is used.

- + optimizer/plan - optimizes path output

@@ -130,7 +129,7 @@ This takes the optimizer/path output, chooses the path with the least cost, and creates a plan for the executor.

- + optimizer/prep - handle special plan cases

@@ -138,7 +137,7 @@ least cost, and creates a plan for the executor. This does special plan processing.

- + optimizer/util - optimizer support routines

@@ -190,31 +189,31 @@ that pre-format user requests into a predefined format. These allow uniform resource access by the backend.

- + storage/buffer - shared buffer pool manager
- + storage/file - file manager
- + storage/ipc - semaphores and shared memory
- + storage/large_object - large objects
- + storage/lmgr - lock manager
- + storage/page - page manager
- + storage/smgr - storage/disk manager
@@ -230,35 +229,35 @@ These control the way data is accessed in heap, indexes, and transactions.

- + access/common - common access routines
- + access/gist - easy-to-define access method system
- + access/hash - hash
- + access/heap - heap is use to store data rows
- + access/index - used by all index types
- + access/nbtree - Lehman and Yao's btree management algorithm
- + access/rtree - used for indexing of 2-dimensional data
- + access/transam - transaction manager (BEGIN/ABORT/COMMIT)
@@ -289,7 +288,7 @@ store requests and data. - support routines

- + utils/adt - built-in data type routines

@@ -297,7 +296,7 @@ store requests and data. This contains all the PostgreSQL builtin data types.

- + utils/cache - system/relation/function cache routines

@@ -314,7 +313,7 @@ This last cache maintains information about all recently-accessed tables, not just system ones.

- + utils/error - error reporting routines

@@ -322,7 +321,7 @@ tables, not just system ones. Reports backend errors to the front end.

- + utils/fmgr - function manager

@@ -331,7 +330,7 @@ This handles the calling of dynamically-loaded functions, and the calling of functions defined in the system tables.

- + utils/hash - hash routines for internal algorithms

@@ -341,17 +340,17 @@ do quick lookups of dynamic data storage structures maintained by the backend.

- + utils/init - various initialization stuff

- + utils/misc - miscellaneous stuff

- + utils/mmgr - memory manager(process-local memory)

@@ -363,7 +362,7 @@ By doing this, the backend can easily free memory once a statement or transaction completes.

- + utils/sort - sort routines for internal algorithms

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

- + utils/time - transaction time qualification routines

@@ -419,13 +418,11 @@ This does processing for the rules system. - unused (array handling?)
-
+
-
Maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
Last updated: Tue Dec 9 17:56:08 EST 1997 -
 diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index 78b8b8e5fa..241c4bb5d5 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -3,42 +3,40 @@ How PostgreSQL Processes a Query -

+

How PostgreSQL Processes a Query

-

+

by Bruce Momjian

-

-flowchart -
- - - - - - - - - - - - - - - - - - +flowchart + +main +postmaster +libpq +tcop +tcop +parser +tcop +optimizer +plan +executor +commands +utils +catalog +storage +access +nodes +bootstrap -
+ Click on an item to see more detail or look at the full index. -
+

- +

A query comes to the backend via data packets arriving through TCP/IP or @@ -49,13 +47,13 @@ into tokens(words). The parser uses gram.y and the tokens to identify the query type, and load the proper query-specific structure, like CreateStmt or SelectStmt.

+HREF="../../include/nodes/parsenodes.h">SelectStmt.

The query is then identified as a Utility query or a more complex query. A Utility query is processed by a query-specific function in commands. A complex query, like -SELECT, UPDATE, and DELETE requires much more handling.

+SELECT, UPDATE, and DELETE requires much more handling.

The parser takes a complex query, and creates a @@ -67,7 +65,7 @@ Each table referenced in the query is represented by a RangeTableEntry, and they are linked together to form the range table of the query, which is generated by -transformFromClause(). Query.rtable holds the query's range table.

+transformFromClause(). Query.rtable holds the query's range table.

Certain queries, like SELECT, return columns of data. Other @@ -78,16 +76,16 @@ placed in target list entries, and linked together to make up the target list of the query. The target list is stored in Query.targetList, which is generated by transformTargetList().

+HREF="../../backend/parser/parse_target.c">transformTargetList().

Other query elements, like aggregates(SUM()), GROUP BY, -and ORDER BY are also stored in their own Query fields.

+and ORDER BY are also stored in their own Query fields.

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 rewrite system.

+HREF="../../backend/rewrite">rewrite system.

The optimizer takes the Query @@ -96,18 +94,17 @@ HREF="../../include/nodes/plannodes.h">Plan, which contains the operations to be performed to execute the query. The path module determines the best table join order and join type of each table in the RangeTable, using -Query.qual(WHERE clause) to consider optimal index usage.

+Query.qual(WHERE clause) to consider optimal index usage.

The Plan is then passed to the executor 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.

- +children.

There are many other modules that support this basic functionality. They -can be accessed by clicking on the flowchart.

+can be accessed by clicking on the flowchart.

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

-Each data structure is created by calling Each data structure is created by calling ShmemInitStruct(), and the lookups are created by ShmemInitHash().

+HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().

-
+
-
Maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
Last updated: Mon Aug 10 10:48:06 EDT 1998 -