3
<TITLE>PostgreSQL Backend Directories</TITLE>
5
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF">
7
PostgreSQL Backend Directories
15
<EM>Click on any of the section headings to see the source code for that section.
19
<A NAME="bootstrap"></A>
20
<A HREF="../../backend/bootstrap">bootstrap</A>
21
- creates initial template database via initdb
24
Because PostgreSQL requires access to system tables for almost every
25
operation, getting those system tables in place is a problem.
26
You can't just create the tables and insert data into them in the normal way,
27
because table creation and insertion requires the tables to already
29
This code <I>jams</I> the data directly into tables using a
30
special syntax used only by the bootstrap procedure.
34
<A HREF="../../backend/main">main</A>
35
- passes control to postmaster or postgres
38
This checks the process name(argv[0]) and various flags, and passes
39
control to the postmaster or postgres backend code.
42
<A NAME="postmaster"></A>
43
<A HREF="../../backend/postmaster">postmaster</A>
44
- controls postgres server startup/termination
47
This creates shared memory, and then goes into a loop waiting for
49
When a connection request arrives, a <I>postgres</I> backend is started,
50
and the connection is passed to it.
54
<A HREF="../../backend/libpq">libpq</A>
55
- backend libpq library routines
58
This handles communication to the client processes.
62
<A HREF="../../backend/tcop">tcop</A>
63
- traffic cop, dispatches request to proper module
66
This contains the <I>postgres</I> backend main handler, as well as the
67
code that makes calls to the parser, optimizer, executor, and
68
<I>/commands</I> functions.
72
<A HREF="../../backend/parser">parser</A>
73
- converts SQL query to query tree
76
This converts SQL queries coming from <I>libpq</I> into command-specific
77
structures to be used the the optimizer/executor, or <I>/commands</I>
79
The SQL is lexically analyzed into keywords, identifiers, and constants,
80
and passed to the parser.
81
The parser creates command-specific structures to hold the elements of
83
The command-specific structures are then broken apart, checked, and passed to
84
<I>/commands</I> processing routines, or converted into <I>Lists</I> of
85
<I>Nodes</I> to be handled by the optimizer and executor.
88
<A NAME="optimizer"></A>
89
<A HREF="../../backend/optimizer">optimizer</A>
90
- creates path and plan
93
This uses the parser output to generate an optimal plan for the
97
<A NAME="optimizer/path"></A>
98
<A HREF="../../backend/optimizer/path">optimizer/path</A>
99
- creates path from parser output
102
This takes the parser query output, and generates all possible methods of
103
executing the request.
104
It examines table join order, <I>where</I> clause restrictions,
105
and optimizer table statistics to evaluate each possible execution
106
method, and assigns a cost to each.
109
<A NAME="optimizer/geqo"></A>
110
<A HREF="../../backend/optimizer/geqo">optimizer/geqo</A>
111
- genetic query optimizer
114
<I>optimizer/path</I> evaluates all possible ways to join the requested tables.
115
When the number of tables becomes great, the number of tests made
117
The Genetic Query Optimizer considers each table separately, then figures
118
the most optimal order to perform the join.
119
For a few tables, this method takes longer, but for a large number of
120
tables, it is faster.
121
There is an option to control when this feature is used.
124
<A NAME="optimizer/plan"></A>
125
<A HREF="../../backend/optimizer/plan">optimizer/plan</A>
126
- optimizes path output
129
This takes the <I>optimizer/path</I> output, chooses the path with the
130
least cost, and creates a plan for the executor.
133
<A NAME="optimizer/prep"></A>
134
<A HREF="../../backend/optimizer/prep">optimizer/prep</A>
135
- handle special plan cases
138
This does special plan processing.
141
<A NAME="optimizer/util"></A>
142
<A HREF="../../backend/optimizer/util">optimizer/util</A>
143
- optimizer support routines
146
This contains support routines used by other parts of the optimizer.
149
<A NAME="executor"></A>
150
<A HREF="../../backend/executor">executor</A>
151
- executes complex node plans from optimizer
154
This handles <I>select, insert, update,</I> and <I>delete</I> statements.
155
The operations required to handle these statement types include
156
heap scans, index scans, sorting, joining tables, grouping, aggregates,
160
<A NAME="commands"></A>
161
<A HREF="../../backend/commands">commands</A>
162
- commands that do not require the executor
165
These process SQL commands that do not require complex handling.
166
It includes <I>vacuum, copy, alter, create table, create type,</I> and
168
The code is called with the structures generated by the parser.
169
Most of the routines do some processing, then call lower-level functions
170
in the catalog directory to do the actual work.
173
<A NAME="catalog"></A>
174
<A HREF="../../backend/catalog">catalog</A>
175
- system catalog manipulation
178
This contains functions that manipulate the system tables or catalogs.
179
Table, index, procedure, operator, type, and aggregate creation and
180
manipulation routines are here.
181
These are low-level routines, and are usually called by upper routines
182
that pre-format user requests into a predefined format.
185
<A NAME="storage"></A>
186
<A HREF="../../backend/storage">storage</A>
187
- manages various storage systems
190
These allow uniform resource access by the backend.
193
<A NAME="storage/buffer"></A>
194
<A HREF="../../backend/storage/buffer">storage/buffer</A>
195
- shared buffer pool manager
197
<A NAME="storage/file"></A>
198
<A HREF="../../backend/storage/file">storage/file</A>
201
<A NAME="storage/ipc"></A>
202
<A HREF="../../backend/storage/ipc">storage/ipc</A>
203
- semaphores and shared memory
205
<A NAME="storage/large_object"></A>
206
<A HREF="../../backend/storage/large_object">storage/large_object</A>
209
<A NAME="storage/lmgr"></A>
210
<A HREF="../../backend/storage/lmgr">storage/lmgr</A>
213
<A NAME="storage/page"></A>
214
<A HREF="../../backend/storage/page">storage/page</A>
217
<A NAME="storage/smgr"></A>
218
<A HREF="../../backend/storage/smgr">storage/smgr</A>
219
- storage/disk manager
224
<A NAME="access"></A>
225
<A HREF="../../backend/access">access</A>
226
- various data access methods
229
These control the way data is accessed in heap, indexes, and
233
<A NAME="access/common"></A>
234
<A HREF="../../backend/access/common">access/common</A>
235
- common access routines
237
<A NAME="access/gist"></A>
238
<A HREF="../../backend/access/gist">access/gist</A>
239
- easy-to-define access method system
241
<A NAME="access/hash"></A>
242
<A HREF="../../backend/access/hash">access/hash</A>
245
<A NAME="access/heap"></A>
246
<A HREF="../../backend/access/heap">access/heap</A>
247
- heap is use to store data rows
249
<A NAME="access/index"></A>
250
<A HREF="../../backend/access/index">access/index</A>
251
- used by all index types
253
<A NAME="access/nbtree"></A>
254
<A HREF="../../backend/access/nbtree">access/nbtree</A>
255
- Lehman and Yao's btree management algorithm
257
<A NAME="access/rtree"></A>
258
<A HREF="../../backend/access/rtree">access/rtree</A>
259
- used for indexing of 2-dimensional data
261
<A NAME="access/transam"></A>
262
<A HREF="../../backend/access/transam">access/transam</A>
263
- transaction manager (BEGIN/ABORT/COMMIT)
269
<A HREF="../../backend/nodes">nodes</A>
270
- creation/manipulation of nodes and lists
273
PostgreSQL stores information about SQL queries in structures called
275
<I>Nodes</I> are generic containers that have a <I>type</I> field and then a
276
type-specific data section.
277
Nodes are usually placed in <I>Lists.</I>
278
A <I>List</I> is container with an <I>elem</I> element,
279
and a <I>next</I> field that points to the next <I>List.</I>
280
These <I>List</I> structures are chained together in a forward linked list.
281
In this way, a chain of <I>List</I>s can contain an unlimited number of <I>Node</I>
282
elements, and each <I>Node</I> can contain any data type.
283
These are used extensively in the parser, optimizer, and executor to
284
store requests and data.
288
<A HREF="../../backend/utils">utils</A>
292
<A NAME="utils/adt"></A>
293
<A HREF="../../backend/utils/adt">utils/adt</A>
294
- built-in data type routines
297
This contains all the PostgreSQL builtin data types.
300
<A NAME="utils/cache"></A>
301
<A HREF="../../backend/utils/cache">utils/cache</A>
302
- system/relation/function cache routines
305
PostgreSQL supports arbitrary data types, so no data types are hard-coded
306
into the core backend routines.
307
When the backend needs to find out about a type, is does a lookup of a
309
Because these system tables are referred to often, a cache is maintained
311
There is a system relation cache, a function/operator cache, and a relation
313
This last cache maintains information about all recently-accessed
314
tables, not just system ones.
317
<A NAME="utils/error"></A>
318
<A HREF="../../backend/utils/error">utils/error</A>
319
- error reporting routines
322
Reports backend errors to the front end.
325
<A NAME="utils/fmgr"></A>
326
<A HREF="../../backend/utils/fmgr">utils/fmgr</A>
330
This handles the calling of dynamically-loaded functions, and the calling
331
of functions defined in the system tables.
334
<A NAME="utils/hash"></A>
335
<A HREF="../../backend/utils/hash">utils/hash</A>
336
- hash routines for internal algorithms
339
These hash routines are used by the cache and memory-manager routines to
340
do quick lookups of dynamic data storage structures maintained by the
344
<A NAME="utils/init"></A>
345
<A HREF="../../backend/utils/init">utils/init</A>
346
- various initialization stuff
349
<A NAME="utils/misc"></A>
350
<A HREF="../../backend/utils/misc">utils/misc</A>
351
- miscellaneous stuff
354
<A NAME="utils/mmgr"></A>
355
<A HREF="../../backend/utils/mmgr">utils/mmgr</A>
356
- memory manager(process-local memory)
359
When PostgreSQL allocates memory, it does so in an explicit context.
360
Contexts can be statement-specific, transaction-specific, or
362
By doing this, the backend can easily free memory once a statement or
363
transaction completes.
366
<A NAME="utils/sort"></A>
367
<A HREF="../../backend/utils/sort">utils/sort</A>
368
- sort routines for internal algorithms
371
When statement output must be sorted as part of a backend operation,
372
this code sorts the tuples, either in memory or using disk files.
375
<A NAME="utils/time"></A>
376
<A HREF="../../backend/utils/time">utils/time</A>
377
- transaction time qualification routines
380
These routines do checking of tuple internal columns to determine if the
381
current row is still valid, or is part of a non-committed transaction or
382
superseded by a new row.
385
<A NAME="include"></A>
386
<A HREF="../../backend/include">include</A>
390
There are include directories for each subsystem.
394
<A HREF="../../backend/lib">lib</A>
398
This houses several generic routines.
402
<A HREF="../../backend/regex">regex</A>
403
- regular expression library
406
This is used for regular expression handling in the backend, i.e. '~'.
409
<A NAME="rewrite"></A>
410
<A HREF="../../backend/rewrite">rewrite</A>
414
This does processing for the rules system.
418
<A HREF="../../backend/tioga">tioga</A>
419
- unused (array handling?)
422
<HR SIZE="2" NOSHADE>
425
Maintainer: Bruce Momjian (<A
426
HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
427
Last updated: Tue Dec 9 17:56:08 EST 1997
added
removed
src/tools/backend/backend_dirs.html
