diff --git a/src/tools/BACKEND_DIRS.html b/src/tools/BACKEND_DIRS.html new file mode 100644 index 0000000000000000000000000000000000000000..0d9a1bc7d9d7f7bfe53f88a04776a17bcd88fe7c --- /dev/null +++ b/src/tools/BACKEND_DIRS.html @@ -0,0 +1,322 @@ +<HTML> +<HEAD> +<TITLE>PostgreSQL Backend Directories</TITLE> +</HEAD> +<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF"> +<H1 ALIGN=CENTER> +PostgreSQL Backend Directories +</H1> +<H2 ALIGN=CENTER> +by Bruce Momjian +</H2 ALIGN=CENTER> +<H2> +<A HREF="../backend//bootstrap">bootstrap</A> - creates initial template database via initdb +</H2> +<P> +Because PostgreSQL requires access to system tables for almost every +operation, getting those system tables in place is a problem. +You can't just create the tables and insert data into them in the normal way, +because table creation and insertion requires the tables to already +exist. +This code <I>jams</I> the data directly into tables using a +special syntax used only by the bootstrap procedure. +</P> +<H2> +<A HREF="../backend//main">main</A> - passes control to postmaster or postgres +</H2> +<P> +This checks the process name(argv[0]) and various flags, and passes +control to the postmaster or postgres backend code. +</P> +<H2> +<A HREF="../backend//postmaster">postmaster</A> - controls postgres server startup/termination +</H2> +<P> +This creates shared memory, and then goes into a loop waiting for +connection requests. +When a connection request arrives, a <I>postgres</I> backend is started, +and the connection is passed to it. +</P> +<H2> +<A HREF="../backend//libpq">libpq</A> - backend libpq library routines +</H2> +<P> +This handles communication to the client processes. +</P> +<H2> +<A HREF="../backend//tcop">tcop</A> - traffic cop, dispatches request to proper module +</H2> +<P> +This contains the <I>postgres</I> backend main handler, as well as the +code that makes calls to the parser, optimizer, executor, and +<I>/commands</I> functions. +</P> +<H2> +<A HREF="../backend//parser">parser</A> - converts SQL query to query tree +</H2> +<P> +This converts SQL queries coming from <I>libpq</I> into command-specific +structures to be used the the optimizer/executor, or <I>/commands</I> +routines. +The SQL is lexically analyzed into keywords, identifiers, and constants, +and passed to the parser. +The parser creates command-specific structures to hold the elements of +the query. +The command-specific structures are then broken apart, checked, and passed to +<I>/commands</I> processing routines, or converted into <I>Lists</I> of +<I>Nodes</I> to be handled by the optimizer and executor. +</P> +<H2> +<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 HREF="../backend//optimizer/path">optimizer/path</A> - creates path from parser output +</H4> +<P> +This takes the parser query output, and generates all possible methods of +executing the request. +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 HREF="../backend//optimizer/geqo">optimizer/geqo</A> - genetic query optimizer +</H4> +<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 +becomes great too. +The Genetic Query Optimizer considers each table separately, then figures +the most optimal order to perform the join. +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 HREF="../backend//optimizer/plan">optimizer/plan</A> - optimizes path output +</H4> +<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 HREF="../backend//optimizer/prep">optimizer/prep</A> - handle special plan cases +</H4> +<P> +This does special plan processing. +</P> +<H4> +<A HREF="../backend//optimizer/util">optimizer/util</A> - optimizer support routines +</H4> +<P> +This contains support routines used by other parts of the optimizer. +</P> +<H2> +<A HREF="../backend//executor">executor</A> - executes complex node plans from optimizer +</H2> +<P> +This handles <I>select, insert, update,</I> and <I>delete</I> statements. +The operations required to handle these statement types include +heap scans, index scans, sorting, joining tables, grouping, aggregates, +and uniqueness. +</P> +<H2> +<A HREF="../backend//commands">commands</A> - commands that do not require the executor +</H2> +<P> +These process SQL commands that do not require complex handling. +It includes <I>vacuum, copy, alter, create table, create type,</I> and +many others. +The code is called with the structures generated by the parser. +Most of the routines do some processing, then call lower-level functions +in the catalog directory to do the actual work. +</P> +<H2> +<A HREF="../backend//catalog">catalog</A> - system catalog manipulation +</H2> +<P> +This contains functions that manipulate the system tables or catalogs. +Table, index, procedure, operator, type, and aggregate creation and +manipulation routines are here. +These are low-level routines, and are usually called by upper routines +that pre-format user requests into a predefined format. +</P> +<H2> +<A HREF="../backend//storage">storage</A> - manages various storage systems +</H2> +<P> +These allow uniform resource access by the backend. +<BR> +<BR> +<A HREF="../backend//storage/buffer">storage/buffer</A> - shared buffer pool manager +<BR> +<A HREF="../backend//storage/file">storage/file</A> - file manager +<BR> +<A HREF="../backend//storage/ipc">storage/ipc</A> - semaphores and shared memory +<BR> +<A HREF="../backend//storage/large_object">storage/large_object</A> - large objects +<BR> +<A HREF="../backend//storage/lmgr">storage/lmgr</A> - lock manager +<BR> +<A HREF="../backend//storage/page">storage/page</A> - page manager +<BR> +<A HREF="../backend//storage/smgr">storage/smgr</A> - storage/disk manager +<BR> +<BR> +</P> +<H2> +<A HREF="../backend//access">access</A> - various data access methods +</H2> +<P> +These control the way data is accessed in heap, indexes, and +transactions. +<BR> +<BR> +<A HREF="../backend//access/common">access/common</A> - common access routines +<BR> +<A HREF="../backend//access/gist">access/gist</A> - easy-to-define access method system +<BR> +<A HREF="../backend//access/hash">access/hash</A> - hash +<BR> +<A HREF="../backend//access/heap">access/heap</A> - heap is use to store data rows +<BR> +<A HREF="../backend//access/index">access/index</A> - used by all index types +<BR> +<A HREF="../backend//access/nbtree">access/nbtree</A> - Lehman and Yao's btree management algorithm +<BR> +<A HREF="../backend//access/rtree">access/rtree</A> - used for indexing of 2-dimensional data +<BR> +<A HREF="../backend//access/transam">access/transam</A> - transaction manager (BEGIN/ABORT/COMMIT) +<BR> +<BR> +</P> +<H2> +<A HREF="../backend//nodes">nodes</A> - creation/manipulation of nodes and lists +</H2> +<P> +PostgreSQL stores information about SQL queries in structures called +nodes. +<I>Nodes</I> are generic containers that have a <I>type</I> field and then a +type-specific data section. +Nodes are usually placed in <I>Lists.</I> +A <I>List</I> is container with an <I>elem</I> element, +and a <I>next</I> field that points to the next <I>List.</I> +These <I>List</I> structures are chained together in a forward linked list. +In this way, a chain of <I>List</I>s can contain an unlimited number of <I>Node</I> +elements, and each <I>Node</I> can contain any data type. +These are used extensively in the parser, optimizer, and executor to +store requests and data. +</P> +<H2> +<A HREF="../backend//utils">utils</A> - support routines +</H2> +<H4> +<A HREF="../backend//utils/adt">utils/adt</A> - built-in data type routines +</H4> +<P> +This contains all the PostgreSQL builtin data types. +</P> +<H4> +<A HREF="../backend//utils/cache">utils/cache</A> - system/relation/function cache routines +</H4> +<P> +PostgreSQL supports arbitrary data types, so no data types are hard-coded +into the core backend routines. +When the backend needs to find out about a type, is does a lookup of a +system table. +Because these system tables are referred to often, a cache is maintained +that speeds lookups. +There is a system relation cache, a function/operator cache, and a relation +information cache. +This last cache maintains information about all recently-accessed +tables, not just system ones. +</P> +<H4> +<A HREF="../backend//utils/error">utils/error</A> - error reporting routines +</H4> +<P> +Reports backend errors to the front end. +</P> +<H4> +<A HREF="../backend//utils/fmgr">utils/fmgr</A> - function manager +</H4> +<P> +This handles the calling of dynamically-loaded functions, and the calling +of functions defined in the system tables. +</P> +<H4> +<A HREF="../backend//utils/hash">utils/hash</A> - hash routines for internal algorithms +</H4> +<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 HREF="../backend//utils/init">utils/init</A> - various initialization stuff +</H4> +<H4> +<A HREF="../backend//utils/misc">utils/misc</A> - miscellaneous stuff +</H4> +<H4> +<A HREF="../backend//utils/mmgr">utils/mmgr</A> - memory manager(process-local memory) +</H4> +<P> +When PostgreSQL allocates memory, it does so in an explicit context. +Contexts can be statement-specific, transaction-specific, or +persistent/global. +By doing this, the backend can easily free memory once a statement or +transaction completes. +</P> +<H4> +<A HREF="../backend//utils/sort">utils/sort</A> - sort routines for internal algorithms +</H4> +<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 HREF="../backend//utils/time">utils/time</A> - transaction time qualification routines +</H4> +<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 HREF="../backend//include">include</A> - include files +</H2> +<P> +There are include directories for each subsystem. +</P> +<H2> +<A HREF="../backend//lib">lib</A> - support library +</H2> +<P> +This houses several generic routines. +</P> +<H2> +<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 HREF="../backend//rewrite">rewrite</A> - rules system +</H2> +<P> +This does processing for the rules system. +</P> +<H2> +<A HREF="../backend//tioga">tioga</A> - unused (array handling?) +</H2> +<HR> +<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 +</ADDRESS>