mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-21 08:29:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update version.

Browse Source
This commit is contained in:
Bruce Momjian 1998-07-20 10:01:51 +00:00
parent 60baf183b3
commit a6ca652508
1 changed files with 14 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
src/tools/backend/index.html
View File

@ -10,6 +10,7 @@ How PostgreSQL Processes a Query
by Bruce Momjian
</H2>
<P>
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
@ -22,12 +23,14 @@ 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> 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
<I>SELECT, UPDATE,</I> and
<I>DELETE</I> requires much more handling.
<P>
The parser takes a complex query, 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
@ -39,6 +42,7 @@ 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 query's range table.
<P>
Certain queries, like <I>SELECT,</I> return columns of data. Other
queries, like <I>INSERT</I> and <I>UPDATE,</I> specify the columns
modified by the query. These column references are converted to <A
@ -49,13 +53,16 @@ the query. The 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(<I>SUM()</I>), <I>GROUP BY,</I>
and <I>ORDER BY</I> are also stored in their own Query fields.
<P>
The next step is for the Query to be modified by any <I>VIEWS</I> or
<I>RULES</I> that may apply to the query. This is performed by the <A
HREF="../../backend/rewrite">rewrite</A> system.
<P>
The <A HREF="../../backend/optimizer">optimizer</A> takes the Query
structure and generates an optimal <A
HREF="../..//include/nodes/plannodes.h">Plan,</A> which contains the
@ -65,18 +72,21 @@ table join order and join type of each table in the RangeTable, using
Query.qual(<I>WHERE</I> 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
returned to the client. The Plan actually as set of nodes, arranged in
a tree structure with a top-level node, and various sub-nodes as
children.
<P>
There are many other modules that support this basic functionality.
They can be accessed by clicking on the flowchart.
<P>
<HR>
<P>
<CENTER>
<EM><BIG>
Click on an item to see more detail or look at the full
@ -107,8 +117,10 @@ Click on an item to see more detail or look at the full
</MAP>
<BR>
<P>
<HR>
<P>
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
@ -147,6 +159,7 @@ 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 SIZE="2" NOSHADE>
<SMALL>
<ADDRESS>