New backend dirs html file.
This commit is contained in:
Bruce Momjian
parent
8cae12b13b
commit
ee08c36dd3
|
|
@ -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>
|
||||
Loading…
Reference in New Issue