1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
<HTML>
<HEAD>
<TITLE>PostgreSQL Backend Flowchart</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF">
<H1 ALIGN=CENTER>
PostgreSQL Backend Flowchart
</H1>
<H2 ALIGN=CENTER>
by Bruce Momjian
</H2 ALIGN=CENTER>
<P>
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
<A HREF="../../backend/parser">parser,</A> where the lexical scanner,
<A HREF="../../backend/parser/scan.l">scan.l,</A>
breaks the query up into tokens(words). The parser
uses
<A HREF="../../backend/parser/gram.y">gram.y</A> and the tokens to
identify the query type, and load the proper query-type-specific
structure, like
<A HREF="../../include/nodes/parsenodes.h">CreateStmt or SelectStmt.</A>
<P>
The query is then identified as a <I>Utility</I> function or a more
complex query. <I>Utility</I> queries are processed by a
query-type-specific function in <A HREF="../../backend/commands">
commands.</A> Complex queries, like <I>SELECT, UPDATE,</I> and
<I>DELETE</I> require much more handling.
<P>
The parser takes the complex queries, and creates a
<A HREF="../../include/nodes/parsenodes.h">Query</A> structure that
contains all the elements used by complex queries. Query.qual holds the
WHERE clause qualification, which is filled in by
<A HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A>
Each table is represented by a <A HREF="../../include/nodes/parsenodes.h">
RangeTableEntry,</A>
and they are linked together to form the <I>range table</I> for the
query, and is generated by <A HREF="../../backend/parser/parse_clause.c">
makeRangeTable().</A> Query.rtable holds the queries range table.
<P>
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 <A
HREF="../../include/nodes/primnodes.h"> Resdom</A> entries, which are
linked together to make up the <I>target list</I> of the query. The
target list is stored in Query.targetList, and is generated by
<A HREF="../../backend/parser/parse_target.c">transformTargetList().</A>
<P>
Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are
also stored in their own fields.
<P>
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 <A
HREF="../../backend/rewrite">rewrite</A> system.
<P>
The optimizer takes the Query structure, and generates an optimal
<A HREF="../..//include/nodes/plannodes.h">Plan</A> containing primitive
operations to be performed by the executor to complete the query. The
<A HREF="../../backend/optimizer/path">path</A> 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.
<P>
The Plan is then passed to the <A
HREF="../../backend/executor">executor</A> for execution, and the result
is returned to the client.
<P>
There are many other modules that support this basic functionality.
They can be accessed by clicking on the flowchart.
<P>
Another area of interest is the shared memory area, containing
table data/index blocks, locks, and backend information:
<UL>
<LI>ShmemIndex - contains an index of all other shared memory
structures, allowing quick lookup of other structure locations in shared
memory
<LI>Buffer Descriptors - control header for shared memory buffer block
<LI>Buffer Blocks - block of table/index data shared by all backends
<LI>Shared Buf Lookup Table - lookup to see if a requested buffer
is already in the shared memory area
<LI>LockTable - lock table structure, specifiying table, lock types, and
backends holding or waiting on lock
<LI>LockTable (lock hash) - lookup of LockTable structures using
table name
<LI>LockTable (xid hash) - lookup of LockTable structures using
transaction id
<LI>Proc Header - information about each backend, including locks held/waiting,
indexed by process id
</UL>
Each structure is created by calling <A
HREF="../../backend/storage/ipc/shmem.c"> ShmemInitStruct().</A>
<HR>
<CENTER>
<EM><BIG>
Click on an item to see more detail or click
<A HREF="backend_dirs.html">here</a> to see the full index.
</EM></BIG>
<BR>
<BR>
<IMG src="flow.jpg" usemap="#flowmap">
</CENTER>
<MAP name="flowmap">
<AREA COORDS="290,10,450,50" HREF="backend_dirs.html#main">
<AREA COORDS="550,10,710,50" HREF="backend_dirs.html#bootstrap">
<AREA COORDS="290,90,450,130," HREF="backend_dirs.html#postmaster">
<AREA COORDS="550,90,710,130," HREF="backend_dirs.html#libpq">
<AREA COORDS="290,170,450,210" HREF="backend_dirs.html#tcop">
<AREA COORDS="550,170,710,210" HREF="backend_dirs.html#tcop">
<AREA COORDS="290,270,450,310" HREF="backend_dirs.html#parser">
<AREA COORDS="290,350,450,390" HREF="backend_dirs.html#tcop">
<AREA COORDS="290,430,450,470" HREF="backend_dirs.html#optimizer">
<AREA COORDS="290,510,450,550" HREF="backend_dirs.html#optimizer/plan">
<AREA COORDS="290,570,450,630" HREF="backend_dirs.html#executor">
<AREA COORDS="550,350,710,390" HREF="backend_dirs.html#commands">
<AREA COORDS="10,330,170,370" HREF="backend_dirs.html#access">
<AREA COORDS="10,390,170,430" HREF="backend_dirs.html#catalog">
<AREA COORDS="10,450,170,490" HREF="backend_dirs.html#utils">
<AREA COORDS="10,510,170,550" HREF="backend_dirs.html#nodes">
<AREA COORDS="10,570,170,610" HREF="backend_dirs.html#storage">
</MAP>
<BR>
<HR SIZE="2" NOSHADE>
<SMALL>
<ADDRESS>
Maintainer: Bruce Momjian (<A
HREF="mailto:maillist@candle.pha.pa.us">maillist@candle.pha.pa.us</A>)<BR>
Last updated: Tue Dec 9 17:56:08 EST 1997
</ADDRESS>
</SMALL>
</BODY>
</HTML>
|
