diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index 2fb2a096af298cdb9349cea61b31052c1bd4aefe..626517293cd2ecec56256edd26504510818a3ff4 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -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>