update
This commit is contained in:
parent
2584029e31
commit
34d595729a
@ -1,31 +1,31 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>PostgreSQL Backend Flowchart</TITLE>
|
||||
<TITLE>How PostgreSQL Processes a Query</TITLE>
|
||||
</HEAD>
|
||||
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF">
|
||||
<H1 ALIGN=CENTER>
|
||||
PostgreSQL Backend Flowchart
|
||||
How PostgreSQL Processes a Query
|
||||
</H1>
|
||||
<H2 ALIGN=CENTER>
|
||||
by Bruce Momjian
|
||||
</H2>
|
||||
<P>
|
||||
A query come into the backend via data packets coming in through TCP/IP
|
||||
and Unix Domain sockets. It is loaded into a string, and passed to
|
||||
A query comes to the backend via data packets arriving through TCP/IP
|
||||
or Unix Domain sockets. It is 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-specific
|
||||
structure, like
|
||||
<A HREF="../../include/nodes/parsenodes.h">CreateStmt or SelectStmt.</A>
|
||||
identify the query type, and load the proper query-specific structure,
|
||||
like <A HREF="../../include/nodes/parsenodes.h">CreateStmt</A> or <A
|
||||
HREF="../../include/nodes/parsenodes.h">SelectStmt.</A>
|
||||
<P>
|
||||
The query is then identified as a <I>Utility</I> function or a more
|
||||
complex query. A <I>Utility</I> query is processed by a
|
||||
query-specific function in <A HREF="../../backend/commands">
|
||||
commands.</A> A complex query, like <CODE>SELECT, UPDATE,</CODE> and
|
||||
The query is then identified as a <I>Utility</I> query or a more complex
|
||||
query. A <I>Utility</I> query is processed by a query-specific function
|
||||
in <A HREF="../../backend/commands"> commands.</A> A complex query, like
|
||||
<CODE>SELECT, UPDATE,</CODE> and
|
||||
<CODE>DELETE</CODE> requires much more handling.
|
||||
<P>
|
||||
The parser takes a complex query, and creates a
|
||||
@ -37,7 +37,7 @@ Each table referenced in the query is represented by a <A
|
||||
HREF="../../include/nodes/parsenodes.h"> RangeTableEntry,</A> and they
|
||||
are linked together to form the <I>range table</I> of the query, which is
|
||||
generated by <A HREF="../../backend/parser/parse_clause.c">
|
||||
makeRangeTable().</A> Query.rtable holds the queries range table.
|
||||
makeRangeTable().</A> Query.rtable holds the query's range table.
|
||||
<P>
|
||||
Certain queries, like <CODE>SELECT,</CODE> return columns of data. Other
|
||||
queries, like <CODE>INSERT</CODE> and <CODE>UPDATE,</CODE> specify the columns
|
||||
@ -48,7 +48,7 @@ target list is stored in Query.targetList, which is generated by
|
||||
<A HREF="../../backend/parser/parse_target.c">transformTargetList().</A>
|
||||
<P>
|
||||
Other query elements, like aggregates(<CODE>SUM()</CODE>), <CODE>GROUP BY,</CODE>
|
||||
<CODE>ORDER BY</CODE> are also stored in their own Query fields.
|
||||
and <CODE>ORDER BY</CODE> are also stored in their own Query fields.
|
||||
<P>
|
||||
The next step is for the Query to be modified by any <CODE>VIEWS</CODE> or
|
||||
<CODE>RULES</CODE> that may apply to the query. This is performed by the <A
|
||||
@ -69,21 +69,22 @@ returned to the client.
|
||||
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, backend information, and lookup tables for
|
||||
these structures:
|
||||
Another area of interest is the shared memory area, which contains data
|
||||
accessable to all backends. It has table recently used data/index
|
||||
blocks, locks, backend information, and lookup tables for these
|
||||
structures:
|
||||
<UL>
|
||||
<LI>ShmemIndex - lookup shared memory addresses using structure names
|
||||
<LI><A HREF="../../include/storage/buf_internals.h">Buffer
|
||||
Descriptors</A> - control header for buffer cache block
|
||||
<LI><A HREF="../../include/storage/buf_internals.h">Buffer Blocks</A> -
|
||||
Descriptor</A> - control header for buffer cache block
|
||||
<LI><A HREF="../../include/storage/buf_internals.h">Buffer Block</A> -
|
||||
data/index buffer cache block
|
||||
<LI>Shared Buf Lookup Table - lookup of buffer cache block address using
|
||||
<LI>Shared Buffer Lookup Table - lookup of buffer cache block addresses using
|
||||
table name and block number(<A HREF="../../include/storage/buf_internals.h">
|
||||
BufferTag</A>)
|
||||
<LI>MultiLevelLockTable (ctl) - <A
|
||||
HREF="../../include/storage/lock.h">LOCKCTL</A> control structure for
|
||||
each locking method. Currently, only multi-level locking is used.
|
||||
<LI>MultiLevelLockTable (ctl) - control structure for
|
||||
each locking method. Currently, only multi-level locking is used(<A
|
||||
HREF="../../include/storage/lock.h">LOCKMETHODCTL</A>).
|
||||
<LI>MultiLevelLockTable (lock hash) - the <A
|
||||
HREF="../../include/storage/lock.h">LOCK</A> structure, looked up using
|
||||
relation, database object ids(<A
|
||||
@ -105,7 +106,9 @@ Each data structure is created by calling <A
|
||||
HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</A> and
|
||||
the lookups are created by
|
||||
<A HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A>
|
||||
<P>
|
||||
<HR>
|
||||
<P>
|
||||
<CENTER>
|
||||
<EM><BIG>
|
||||
Click on an item to see more detail or
|
||||
|
Loading…
x
Reference in New Issue
Block a user