From 0cba5523013ee058aa901b3d1013ca7a0a8e2bb9 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 28 Jun 1998 06:17:14 +0000 Subject: [PATCH] Update backend flowchart. --- src/backend/storage/ipc/shmem.c | 4 +- src/tools/backend/backend_dirs.html | 272 ++++++++++++++-------------- src/tools/backend/index.html | 97 +++++++++- 3 files changed, 233 insertions(+), 140 deletions(-) diff --git a/src/backend/storage/ipc/shmem.c b/src/backend/storage/ipc/shmem.c index 0a29a19c0f..247a2bc62a 100644 --- a/src/backend/storage/ipc/shmem.c +++ b/src/backend/storage/ipc/shmem.c @@ -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 diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html index c5bd3a52fe..63b4a3421a 100644 --- a/src/tools/backend/backend_dirs.html +++ b/src/tools/backend/backend_dirs.html @@ -8,15 +8,16 @@ PostgreSQL Backend Directories

by Bruce Momjian -

+

+

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

- -bootstrap + +bootstrap - creates initial template database via initdb

@@ -29,8 +30,8 @@ This code jams the data directly into tables using a special syntax used only by the bootstrap procedure.

- -main + +main - passes control to postmaster or postgres

@@ -38,8 +39,8 @@ This checks the process name(argv[0]) and various flags, and passes control to the postmaster or postgres backend code.

- -postmaster + +postmaster - controls postgres server startup/termination

@@ -49,16 +50,16 @@ When a connection request arrives, a postgres backend is started, and the connection is passed to it.

- -libpq + +libpq - backend libpq library routines

This handles communication to the client processes.

- -tcop + +tcop - traffic cop, dispatches request to proper module

@@ -67,8 +68,8 @@ code that makes calls to the parser, optimizer, executor, and /commands functions.

- -parser + +parser - converts SQL query to query tree

@@ -84,19 +85,19 @@ The command-specific structures are then broken apart, checked, and passed to Nodes to be handled by the optimizer and executor.

- -optimizer + +optimizer - creates path and plan

This uses the parser output to generate an optimal plan for the executor.

-

- -optimizer/path +

+ +optimizer/path - creates path from parser output -

+

This takes the parser query output, and generates all possible methods of executing the request. @@ -104,11 +105,11 @@ It examines table join order, where clause restrictions, and optimizer table statistics to evaluate each possible execution method, and assigns a cost to each.

-

- -optimizer/geqo +

+ +optimizer/geqo - genetic query optimizer -

+

optimizer/path 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.

-

- -optimizer/plan +

+ +optimizer/plan - optimizes path output -

+

This takes the optimizer/path output, chooses the path with the least cost, and creates a plan for the executor.

-

- -optimizer/prep +

+ +optimizer/prep - handle special plan cases -

+

This does special plan processing.

-

- -optimizer/util +

+ +optimizer/util - optimizer support routines -

+

This contains support routines used by other parts of the optimizer.

- -executor + +executor - executes complex node plans from optimizer

@@ -156,8 +157,8 @@ heap scans, index scans, sorting, joining tables, grouping, aggregates, and uniqueness.

- -commands + +commands - commands that do not require the executor

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

- -catalog + +catalog - system catalog manipulation

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

- -storage + +storage - manages various storage systems

These allow uniform resource access by the backend.

- -storage/buffer + +storage/buffer - shared buffer pool manager
- -storage/file + +storage/file - file manager
- -storage/ipc + +storage/ipc - semaphores and shared memory
- -storage/large_object + +storage/large_object - large objects
- -storage/lmgr + +storage/lmgr - lock manager
- -storage/page + +storage/page - page manager
- -storage/smgr + +storage/smgr - storage/disk manager

- -access + +access - various data access methods

@@ -229,43 +230,43 @@ These control the way data is accessed in heap, indexes, and transactions.

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

- -nodes + +nodes - creation/manipulation of nodes and lists

@@ -283,23 +284,23 @@ These are used extensively in the parser, optimizer, and executor to store requests and data.

- -utils + +utils - support routines

-

- -utils/adt +

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

+

This contains all the PostgreSQL builtin data types.

-

- -utils/cache +

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

+

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.

-

- -utils/error +

+ +utils/error - error reporting routines -

+

Reports backend errors to the front end.

-

- -utils/fmgr +

+ +utils/fmgr - function manager -

+

This handles the calling of dynamically-loaded functions, and the calling of functions defined in the system tables.

-

- -utils/hash +

+ +utils/hash - hash routines for internal algorithms -

+

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.

-

- -utils/init +

+ +utils/init - various initialization stuff -

-

- -utils/misc +

+

+ +utils/misc - miscellaneous stuff -

-

- -utils/mmgr +

+

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

+

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.

-

- -utils/sort +

+ +utils/sort - sort routines for internal algorithms -

+

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 +

+ +utils/time - transaction time qualification routines -

+

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.

- -include + +include - include files

There are include directories for each subsystem.

- -lib + +lib - support library

This houses several generic routines.

- -regex + +regex - regular expression library

This is used for regular expression handling in the backend, i.e. '~'.

- -rewrite + +rewrite - rules system

This does processing for the rules system.

- -tioga + +tioga - unused (array handling?)

-
+
+
+
-Maintainer: Bruce Momjianmaillist@candle.pha.pa.us)
-Last updated: Mon Oct 27 11:01:08 EST 1997 +Maintainer: Bruce Momjian (maillist@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 04166222af..e286b6d8c6 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -9,8 +9,90 @@ PostgreSQL Backend Flowchart

by Bruce Momjian

+

+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 +parser, where the lexical scanner, +scan.l, +breaks the query up into tokens(words). The parser +uses +gram.y and the tokens to +identify the query type, and load the proper query-type-specific +structure, like +CreateStmt or SelectStmt. +

+The query is then identified as a Utility function or a more +complex query. Utility queries are processed by a +query-type-specific function in +commands. Complex queries, like SELECT, UPDATE, and +DELETE require much more handling. +

+The parser takes the complex queries, and creates a +Query structure that +contains all the elements used by complex queries. Query.qual holds the +WHERE clause qualification, which is filled in by + +transformWhereClause(). +Each table is represented by a +RangeTableEntry, +and they are linked together to form the range table for the +query, and is generated by +makeRangeTable(). Query.rtable holds the queries range table. +

+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 Resdom entries, which are +linked together to make up the target list of the query. The +target list is stored in Query.targetList, and is generated by +transformTargetList(). +

+Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are +also stored in their own 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. +

+The optimizer takes the Query structure, and generates an optimal +Plan containing primitive +operations to be performed by the executor to complete the query. The +path 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. +

+The Plan is then passed to the executor for execution, and the result +is returned to the client. +

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

+Another area of interest is the shared memory area, containing +table data/index blocks, locks, and backend information: +

+Each structure is created by calling ShmemInitStruct(). +
-
Click on an item to see more detail or click here to see the full index. @@ -38,9 +120,14 @@ Click on an item to see more detail or click -
+
+
+
-Maintainer: Bruce Momjianmaillist@candle.pha.pa.us)
-Last updated: Mon Oct 27 11:01:08 EST 1997 +Maintainer: Bruce Momjian (maillist@candle.pha.pa.us)
+Last updated: Tue Dec 9 17:56:08 EST 1997
+ + +