<TITLE>PostgreSQL Backend Directories</TITLE>

<BODYBGCOLOR="#FFFFFF"TEXT="#000000"LINK="#FF0000"VLINK="#A00000"ALINK="#0000FF">

<H1ALIGN=CENTER>

PostgreSQL Backend Directories

<H2ALIGN=CENTER>

by Bruce Momjian

</H2 ALIGN=CENTER>

<AHREF="../backend//bootstrap">bootstrap</A> - creates initial template database via initdb

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.

<AHREF="../backend//main">main</A> - passes control to postmaster or postgres

This checks the process name(argv[0]) and various flags, and passes

control to the postmaster or postgres backend code.

<AHREF="../backend//postmaster">postmaster</A> - controls postgres server startup/termination

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.

<AHREF="../backend//libpq">libpq</A> - backend libpq library routines

This handles communication to the client processes.

<AHREF="../backend//tcop">tcop</A> - traffic cop, dispatches request to proper module

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.

<AHREF="../backend//parser">parser</A> - converts SQL query to query tree

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.

<AHREF="../backend//optimizer">optimizer</A> - creates path and plan

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

executor.

<AHREF="../backend//optimizer/path">optimizer/path</A> - creates path from parser output

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.

<AHREF="../backend//optimizer/geqo">optimizer/geqo</A> - genetic query optimizer

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

<AHREF="../backend//optimizer/plan">optimizer/plan</A> - optimizes path output

This takes the<I>optimizer/path</I> output, chooses the path with the

least cost, and creates a plan for the executor.

<AHREF="../backend//optimizer/prep">optimizer/prep</A> - handle special plan cases

This does special plan processing.

<AHREF="../backend//optimizer/util">optimizer/util</A> - optimizer support routines

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

<AHREF="../backend//executor">executor</A> - executes complex node plans from optimizer

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.

<AHREF="../backend//commands">commands</A> - commands that do not require the executor

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.

<AHREF="../backend//catalog">catalog</A> - system catalog manipulation

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.

<AHREF="../backend//storage">storage</A> - manages various storage systems

These allow uniform resource access by the backend.

<AHREF="../backend//storage/buffer">storage/buffer</A> - shared buffer pool manager

<AHREF="../backend//storage/file">storage/file</A> - file manager

<AHREF="../backend//storage/ipc">storage/ipc</A> - semaphores and shared memory

<AHREF="../backend//storage/large_object">storage/large_object</A> - large objects

<AHREF="../backend//storage/lmgr">storage/lmgr</A> - lock manager

<AHREF="../backend//storage/page">storage/page</A> - page manager

<AHREF="../backend//storage/smgr">storage/smgr</A> - storage/disk manager

<AHREF="../backend//access">access</A> - various data access methods

These control the way data is accessed in heap, indexes, and

transactions.

<AHREF="../backend//access/common">access/common</A> - common access routines

<AHREF="../backend//access/gist">access/gist</A> - easy-to-define access method system

<AHREF="../backend//access/hash">access/hash</A> - hash

<AHREF="../backend//access/heap">access/heap</A> - heap is use to store data rows

<AHREF="../backend//access/index">access/index</A> - used by all index types

<AHREF="../backend//access/nbtree">access/nbtree</A> - Lehman and Yao's btree management algorithm

<AHREF="../backend//access/rtree">access/rtree</A> - used for indexing of 2-dimensional data

<AHREF="../backend//access/transam">access/transam</A> - transaction manager (BEGIN/ABORT/COMMIT)

<AHREF="../backend//nodes">nodes</A> - creation/manipulation of nodes and lists

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.

<AHREF="../backend//utils">utils</A> - support routines

<AHREF="../backend//utils/adt">utils/adt</A> - built-in data type routines

This contains all the PostgreSQL builtin data types.

<AHREF="../backend//utils/cache">utils/cache</A> - system/relation/function cache routines

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.

<AHREF="../backend//utils/error">utils/error</A> - error reporting routines

Reports backend errors to the front end.

<AHREF="../backend//utils/fmgr">utils/fmgr</A> - function manager

This handles the calling of dynamically-loaded functions, and the calling

of functions defined in the system tables.

<AHREF="../backend//utils/hash">utils/hash</A> - 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.

<AHREF="../backend//utils/init">utils/init</A> - various initialization stuff

<AHREF="../backend//utils/misc">utils/misc</A> - miscellaneous stuff

<AHREF="../backend//utils/mmgr">utils/mmgr</A> - memory manager(process-local memory)

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.

<AHREF="../backend//utils/sort">utils/sort</A> - 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.

<AHREF="../backend//utils/time">utils/time</A> - 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.

<AHREF="../backend//include">include</A> - include files

There are include directories for each subsystem.

<AHREF="../backend//lib">lib</A> - support library

This houses several generic routines.

<AHREF="../backend//regex">regex</A> - regular expression library

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

<AHREF="../backend//rewrite">rewrite</A> - rules system

This does processing for the rules system.

<AHREF="../backend//tioga">tioga</A> - unused (array handling?)

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