@@ -8,104 +8,101 @@ <H1 ALIGN=CENTER>
88</ H1 >
99< H2 ALIGN =CENTER >
1010by Bruce Momjian
11- </ H2 ALIGN=CENTER >
11+ </ H2 >
1212< P >
13- Queries come into the backend via data packets coming in through TCP/IP
14- and Unix Domain sockets. They are loaded into a string, and passed to
13+ A query come into the backend via data packets coming in through TCP/IP
14+ and Unix Domain sockets. It is loaded into a string, and passed to
1515the
1616< A HREF ="../../backend/parser "> parser,</ A > where the lexical scanner,
1717< A HREF ="../../backend/parser/scan.l "> scan.l,</ A >
1818breaks the query up into tokens(words). The parser
1919uses
2020< A HREF ="../../backend/parser/gram.y "> gram.y</ A > and the tokens to
21- identify the query type, and load the proper query-type- specific
21+ identify the query type, and load the proper query-specific
2222structure, like
2323< A HREF ="../../include/nodes/parsenodes.h "> CreateStmt or SelectStmt.</ A >
2424< P >
2525The query is then identified as a < I > Utility</ I > function or a more
26- complex query. < I > Utility</ I > queries are processed by a
27- query-type- specific function in < A HREF ="../../backend/commands ">
28- commands.</ A > Complex queries , like < I > SELECT, UPDATE,</ I > and
29- < I > DELETE</ I > require much more handling.
26+ complex query. A < I > Utility</ I > query is processed by a
27+ query-specific function in < A HREF ="../../backend/commands ">
28+ commands.</ A > A complex query , like < B > SELECT, UPDATE,</ B > and
29+ < B > DELETE</ B > requires much more handling.
3030< P >
31- The parser takes the complex queries , and creates a
31+ The parser takes a complex query , and creates a
3232< A HREF ="../../include/nodes/parsenodes.h "> Query</ A > structure that
3333contains all the elements used by complex queries. Query.qual holds the
34- WHERE clause qualification, which is filled in by
34+ < B > WHERE</ B > clause qualification, which is filled in by
3535< A HREF ="../../backend/parser/parse_clause.c "> transformWhereClause().</ A >
3636Each table referenced in the query is represented by a < A
3737HREF ="../../include/nodes/parsenodes.h "> RangeTableEntry,</ A > and they
3838are linked together to form the < I > range table</ I > of the query, which is
3939generated by < A HREF ="../../backend/parser/parse_clause.c ">
4040makeRangeTable().</ A > Query.rtable holds the queries range table.
4141< P >
42- Certain queries, like SELECT, return columns of data. Other queries,
43- like INSERT and UPDATE, specify the columns modified by the query.
44- These column references are converted to < A
45- HREF ="../../include/nodes/primnodes.h "> Resdom</ A > entries, which are
42+ Certain queries, like < B > SELECT,</ B > return columns of data. Other
43+ queries, like < B > INSERT</ B > and < B > UPDATE,</ B > specify the columns
44+ modified by the query. These column references are converted to < A
45+ HREF ="../../include/nodes/primnodes.h "> Resdom</ A > entries, which are
4646linked together to make up the < I > target list</ I > of the query. The
4747target list is stored in Query.targetList, which is generated by
4848< A HREF ="../../backend/parser/parse_target.c "> transformTargetList().</ A >
4949< P >
50- Other query elements, like aggregates(SUM()), GROUP BY, ORDER BY are
51- also stored in their own Query fields.
50+ Other query elements, like aggregates(< B > SUM()</ B > ), < B > GROUP BY,</ B >
51+ < B > ORDER BY </ B > are also stored in their own Query fields.
5252< P >
53- The next step is for the Query to be modified by any VIEWS or RULES that
54- may apply to the query. This is performed by the < A
53+ The next step is for the Query to be modified by any < B > VIEWS</ B > or
54+ < B > RULES </ B > that may apply to the query. This is performed by the < A
5555HREF ="../../backend/rewrite "> rewrite</ A > system.
5656< P >
5757The < A HREF ="../../backend/optimizer "> optimizer</ A > takes the Query
58- structure, and generates an optimal
59- < A HREF ="../..//include/nodes/plannodes.h "> Plan</ A > containing the
60- primitive operations to be performed by the executor to execute the
61- query. The < A HREF ="../../backend/optimizer/path "> path</ A > module
62- determines the best table join order and join type of each table in the
63- RangeTable, using Query.qual(WHERE clause) to consider optimal index
64- usage.
58+ structure and generates an optimal < A
59+ HREF ="../..//include/nodes/plannodes.h "> Plan,</ A > which contains the
60+ operations to be performed to execute the query. The < A
61+ HREF ="../../backend/optimizer/path "> path</ A > module determines the best
62+ table join order and join type of each table in the RangeTable, using
63+ Query.qual(< B > WHERE</ B > clause) to consider optimal index usage.
6564< P >
6665The Plan is then passed to the < A
6766HREF ="../../backend/executor "> executor</ A > for execution, and the result
68- is returned to the client.
67+ returned to the client.
6968< P >
70- There are many other modules that support this basic functionality.
69+ There are many other modules that support this basic functionality.
7170They can be accessed by clicking on the flowchart.
7271< P >
7372Another area of interest is the shared memory area, containing
7473table data/index blocks, locks, and backend information:
7574< UL >
76- < LI > ShmemIndex - contains an index of all other shared memory
77- structures, allowing quick lookup of other structure locations in shared
78- memory
75+ < LI > ShmemIndex - lookup of shared memory addresses using structure names
7976< LI > < A HREF ="../../include/storage/buf_internals.h "> Buffer
80- Descriptors</ A > - control header for shared memory buffer block
81-
82- < LI > < A HREF =" ../../include/storage/buf_internals.h " > Buffer Blocks </ A >
83- - block of table/index data shared by all backends
84- < LI > Shared Buf Lookup Table - lookup to see if a requested buffer
85- is already in the shared memory area
86- < LI > < A HREF ="../../include/storage/lock.h "> LockTable</ A >
87- - lock table structure, specifiying table, lock types, and
88- backends holding or waiting on lock
89- < LI > LockTable (lock hash) - lookup of LockTable structures using
90- table name
77+ Descriptors</ A > - control header for buffer cache block
78+ < LI > < A HREF =" ../../include/storage/buf_internals.h " > Buffer Blocks </ A > -
79+ data/index buffer cache block
80+ < LI > Shared Buf Lookup Table - lookup of buffer cache block address using
81+ table name and block number( < A HREF =" ../../include/storage/buf_internals.h " >
82+ BufferTag </ A > )
83+ < LI > < A HREF ="../../include/storage/lock.h "> LockTable (ctl) </ A > - lock table
84+ structure, specifiying table, lock types, and backends holding or
85+ waiting on lock
86+ < LI > LockTable (lock hash) - lookup of LockTable structures using relation
87+ and database object ids
9188< LI > LockTable (xid hash) - lookup of LockTable structures using
9289transaction id
9390< LI > < A HREF ="../../include/storage/proc.h "> Proc Header</ A > - information
9491about each backend, including locks held/waiting, indexed by process id
9592</ UL >
9693Each data structure is created by calling < A
97- HREF ="../../backend/storage/ipc/shmem.c "> ShmemInitStruct(),</ A > and
98- the lookup hashes are created by
94+ HREF ="../../backend/storage/ipc/shmem.c "> ShmemInitStruct(),</ A > and
95+ the lookups are created by
9996< A HREF ="../../backend/storage/ipc/shmem.c "> ShmemInitHash().</ A >
10097< HR >
10198< CENTER >
10299< EM > < BIG >
103- Click on an item to see more detail or click
104- < A HREF ="backend_dirs.html "> here </ a > to see the full index.
105- </ EM > </ BIG >
100+ Click on an item to see more detail or
101+ < A HREF ="backend_dirs.html "> click </ A > to see the full index.
102+ </ BIG > </ EM >
106103< BR >
107104< BR >
108- < IMG src ="flow.jpg " usemap ="#flowmap ">
105+ < IMG src ="flow.jpg " usemap ="#flowmap " alt =" flowchart " >
109106</ CENTER >
110107< MAP name ="flowmap ">
111108< AREA COORDS ="290,10,450,50 " HREF ="backend_dirs.html#main ">
0 commit comments