Skip to content

P
Postgres FD Implementation
Commit 8903592b authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Update backend flowchard wording

parent 6ceebcac
Hide whitespace changes
Inline Side-by-side
Showing with 167 additions and 162 deletions
src/tools/backend/index.html
View file @ 8903592b
<HTML> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<HEAD> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<TITLE>How PostgreSQL Processes a Query</TITLE> <html xmlns="http://www.w3.org/1999/xhtml">
</HEAD> <head>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF"> <meta name="generator"
<H1> content="HTML Tidy for BSD/OS (vers 1st July 2002), see www.w3.org" />
How PostgreSQL Processes a Query <title>How PostgreSQL Processes a Query</title>
</H1> </head>
<H2> <body bgcolor="#FFFFFF" text="#000000" link="#FF0000"
by Bruce Momjian vlink="#A00000" alink="#0000FF">
</H2> <h1>How PostgreSQL Processes a Query</h1>
<P>
<IMG src="flow.gif" usemap="#flowmap" alt="flowchart"> <h2>by Bruce Momjian</h2>
<MAP name="flowmap" id="flowmap">
<AREA coords="125,35,245,65" HREF="backend_dirs.html#main" alt="main"></AREA> <p><img src="flow.gif" usemap="#flowmap" alt="flowchart" />
<AREA coords="125,100,245,125" HREF="backend_dirs.html#postmaster" alt="postmaster"></AREA>
<AREA coords="325,65,450,95" HREF="backend_dirs.html#libpq" alt="libpq"></AREA> <em>Click on an item to see more detail or look at the full
<AREA coords="125,160,245,190" HREF="backend_dirs.html#tcop" alt="tcop"></AREA> <a href="backend_dirs.html">index.</a></em>
<AREA coords="325,160,450,190" HREF="backend_dirs.html#tcop" alt="tcop"></AREA>
<AREA coords="125,240,245,265" HREF="backend_dirs.html#parser" alt="parser"></AREA> <map name="flowmap" id="flowmap">
<AREA coords="125,300,250,330" HREF="backend_dirs.html#tcop" alt="tcop"></AREA> <area coords="125,35,245,65" href="backend_dirs.html#main" alt="main" />
<AREA coords="125,360,250,390" HREF="backend_dirs.html#optimizer" alt="optimizer"></AREA> <area coords="125,100,245,125" href="backend_dirs.html#postmaster" alt="postmaster" />
<AREA coords="125,425,245,455" HREF="backend_dirs.html#optimizer_plan" alt="plan"></AREA> <area coords="325,65,450,95" href="backend_dirs.html#libpq" alt="libpq" />
<AREA coords="125,490,245,515" HREF="backend_dirs.html#executor" alt="executor"></AREA> <area coords="125,160,245,190" href="backend_dirs.html#tcop" alt="tcop" />
<AREA coords="325,300,450,330" HREF="backend_dirs.html#commands" alt="commands"></AREA> <area coords="325,160,450,190" href="backend_dirs.html#tcop" alt="tcop" />
<AREA coords="75,575,195,605" HREF="backend_dirs.html#utils" alt="utils"></AREA> <area coords="125,240,245,265" href="backend_dirs.html#parser" alt="parser" />
<AREA coords="235,575,360,605" HREF="backend_dirs.html#catalog" alt="catalog"></AREA> <area coords="125,300,250,330" href="backend_dirs.html#tcop" alt="tcop" />
<AREA coords="405,575,525,605" HREF="backend_dirs.html#storage" alt="storage"></AREA> <area coords="125,360,250,390" href="backend_dirs.html#optimizer" alt="optimizer" />
<AREA coords="155,635,275,665" HREF="backend_dirs.html#access" alt="access"></AREA> <area coords="125,425,245,455" href="backend_dirs.html#optimizer_plan" alt="plan" />
<AREA coords="325,635,450,665" HREF="backend_dirs.html#nodes" alt="nodes"></AREA> <area coords="125,490,245,515" href="backend_dirs.html#executor" alt="executor" />
<AREA coords="75,705,200,730" HREF="backend_dirs.html#bootstrap" alt="bootstrap"></AREA> <area coords="325,300,450,330" href="backend_dirs.html#commands" alt="commands" />
</MAP> <area coords="75,575,195,605" href="backend_dirs.html#utils" alt="utils" />
<EM> <area coords="235,575,360,605" href="backend_dirs.html#catalog" alt="catalog" />
Click on an item to see more detail or look at the full <area coords="405,575,525,605" href="backend_dirs.html#storage" alt="storage" />
<A HREF="backend_dirs.html">index.</A> <area coords="155,635,275,665" href="backend_dirs.html#access" alt="access" />
</EM> <area coords="325,635,450,665" href="backend_dirs.html#nodes" alt="nodes" />
<BR> <area coords="75,705,200,730" href="backend_dirs.html#bootstrap" alt="bootstrap" />
<BR> </map>
</P>
<P> <br />
A query comes to the backend via data packets arriving through TCP/IP or <p>A query comes to the backend via data packets arriving through
Unix Domain sockets. It is loaded into a string, and passed to the TCP/IP or Unix Domain sockets. It is loaded into a string, and
<A HREF="../../backend/parser">parser,</A> where the lexical scanner, passed to the <a href="../../backend/parser">parser,</a> where the
<A HREF="../../backend/parser/scan.l">scan.l,</A> breaks the query up lexical scanner, <a href="../../backend/parser/scan.l">scan.l,</a>
into tokens(words). The parser uses <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 href="../../backend/parser/gram.y">gram.y</a> and the tokens to
the query type, and load the proper query-specific structure, like <A identify the query type, and load the proper query-specific
HREF="../../include/nodes/parsenodes.h">CreateStmt</A> or <A structure, like <a
HREF="../../include/nodes/parsenodes.h">SelectStmt.</A></P><P> 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 <p>The statement is then identified as complex (<i>SELECT / INSERT /
query. A <I>Utility</I> query is processed by a query-specific function UPDATE / DELETE</i>) or a simple, e.g <i> CREATE USER, ANALYZE, </i>,
in <A HREF="../../backend/commands"> commands.</A> A complex query, like etc. Utility commands are processed by statement-specific functions in <a
<I>SELECT, UPDATE,</I> and <I>DELETE</I> requires much more handling.</P><P> href="../../backend/commands">backend/commands.</a> Complex statements
require more handling.</p>
The parser takes a complex query, and creates a <p>The parser takes a complex query, and creates a <a
<A HREF="../../include/nodes/parsenodes.h">Query</A> structure that href="../../include/nodes/parsenodes.h">Query</a> structure that
contains all the elements used by complex queries. Query.qual holds the contains all the elements used by complex queries. Query.qual holds
<I>WHERE</I> clause qualification, which is filled in by <A the <i>WHERE</i> clause qualification, which is filled in by <a
HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A> href="../../backend/parser/parse_clause.c">transformWhereClause().</a>
Each table referenced in the query is represented by a <A Each table referenced in the query is represented by a <a
HREF="../../include/nodes/parsenodes.h"> RangeTableEntry,</A> and they href="../../include/nodes/parsenodes.h">RangeTableEntry,</a> and
are linked together to form the <I>range table</I> of the query, which they are linked together to form the <i>range table</i> of the
is generated by <A HREF="../../backend/parser/parse_clause.c"> query, which is generated by <a
transformFromClause().</A> Query.rtable holds the query's range table.</P><P> href="../../backend/parser/parse_clause.c">transformFromClause().</a>
Query.rtable holds the query's range table.</p>
Certain queries, like <I>SELECT,</I> return columns of data. Other <p>Certain queries, like <i>SELECT,</i> return columns of data.
queries, like <I>INSERT</I> and <I>UPDATE,</I> specify the columns Other queries, like <i>INSERT</i> and <i>UPDATE,</i> specify the
modified by the query. These column references are converted to <A columns modified by the query. These column references are
HREF="../../include/nodes/primnodes.h">TargetEntry</A> entries, which are converted to <a
linked together to make up the <I>target list</I> of href="../../include/nodes/primnodes.h">TargetEntry</a> entries,
the query. The target list is stored in Query.targetList, which is which are linked together to make up the <i>target list</i> of the
generated by <A query. The target list is stored in Query.targetList, which is
HREF="../../backend/parser/parse_target.c">transformTargetList().</A></P><P> generated by <a
href="../../backend/parser/parse_target.c">transformTargetList().</a></p>
Other query elements, like aggregates(<I>SUM()</I>), <I>GROUP BY,</I> <p>Other query elements, like aggregates(<i>SUM()</i>), <i>GROUP
and <I>ORDER BY</I> are also stored in their own Query fields.</P><P> 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 <p>The next step is for the Query to be modified by any
<I>RULES</I> that may apply to the query. This is performed by the <A <i>VIEWS</i> or <i>RULES</i> that may apply to the query. This is
HREF="../../backend/rewrite">rewrite</A> system.</P><P> performed by the <a href="../../backend/rewrite">rewrite</a>
system.</p>
The <A HREF="../../backend/optimizer">optimizer</A> takes the Query <p>The <a href="../../backend/optimizer">optimizer</a> takes the
structure and generates an optimal <A Query structure and generates an optimal <a
HREF="../../include/nodes/plannodes.h">Plan,</A> which contains the href="../../include/nodes/plannodes.h">Plan,</a> which contains the
operations to be performed to execute the query. The <A operations to be performed to execute the query. The <a
HREF="../../backend/optimizer/path">path</A> module determines the best href="../../backend/optimizer/path">path</a> module determines the
table join order and join type of each table in the RangeTable, using best table join order and join type of each table in the
Query.qual(<I>WHERE</I> clause) to consider optimal index usage.</P><P> RangeTable, using Query.qual(<i>WHERE</i> clause) to consider
optimal index usage.</p>
The Plan is then passed to the <A <p>The Plan is then passed to the <a
HREF="../../backend/executor">executor</A> for execution, and the result href="../../backend/executor">executor</a> for execution, and the
returned to the client. The Plan actually as set of nodes, arranged in result returned to the client. The Plan actually as set of nodes,
a tree structure with a top-level node, and various sub-nodes as arranged in a tree structure with a top-level node, and various
children.</P><P> sub-nodes as children.</p>
There are many other modules that support this basic functionality. They <p>There are many other modules that support this basic
can be accessed by clicking on the flowchart.</P> functionality. They can be accessed by clicking on the
flowchart.</p>
<HR><P> <hr />
<p>Another area of interest is the shared memory area, which
contains data accessable to all backends. It has recently used
Another area of interest is the shared memory area, which contains data data/index blocks, locks, backend process information, and lookup
accessable to all backends. It has recently used data/index blocks, tables for these structures:</p>
locks, backend process information, and lookup tables for these
structures: <ul>
</P> <li>ShmemIndex - lookup shared memory addresses using structure
names</li>
<UL>
<LI>ShmemIndex - lookup shared memory addresses using structure names</LI> <li><a href="../../include/storage/buf_internals.h">Buffer
<LI><A HREF="../../include/storage/buf_internals.h">Buffer Descriptor</a> - control header for buffer cache block</li>
Descriptor</A> - control header for buffer cache block</LI>
<LI><A HREF="../../include/storage/buf_internals.h">Buffer Block</A> - <li><a href="../../include/storage/buf_internals.h">Buffer
data/index buffer cache block</LI> Block</a> - data/index buffer cache block</li>
<LI>Shared Buffer Lookup Table - lookup of buffer cache block addresses
using table name and block number(<A <li>Shared Buffer Lookup Table - lookup of buffer cache block
HREF="../../include/storage/buf_internals.h"> BufferTag</A>)</LI> addresses using table name and block number( <a
<LI>MultiLevelLockTable (ctl) - control structure for each locking href="../../include/storage/buf_internals.h">BufferTag</a>)</li>
method. Currently, only multi-level locking is used(<A
HREF="../../include/storage/lock.h">LOCKMETHODCTL</A>).</LI> <li>MultiLevelLockTable (ctl) - control structure for each locking
<LI>MultiLevelLockTable (lock hash) - the <A method. Currently, only multi-level locking is used(<a
HREF="../../include/storage/lock.h">LOCK</A> structure, looked up using href="../../include/storage/lock.h">LOCKMETHODCTL</a>).</li>
relation, database object ids(<A
HREF="../../include/storage/lock.h">LOCKTAG)</A>. The lock table <li>MultiLevelLockTable (lock hash) - the <a
structure contains the lock modes(read/write or shared/exclusive) and href="../../include/storage/lock.h">LOCK</a> structure, looked up
circular linked list of backends (<A using relation, database object ids(<a
HREF="../../include/storage/proc.h">PROC</A> structure pointers) waiting href="../../include/storage/lock.h">LOCKTAG)</a>. The lock table
on the lock.</LI> structure contains the lock modes(read/write or shared/exclusive)
<LI>MultiLevelLockTable (xid hash) - lookup of LOCK structure address and circular linked list of backends (<a
using transaction id, LOCK address. It is used to quickly check if the href="../../include/storage/proc.h">PROC</a> structure pointers)
current transaction already has any locks on a table, rather than having waiting on the lock.</li>
to search through all the held locks. It also stores the modes
(read/write) of the locks held by the current transaction. The returned <li>MultiLevelLockTable (xid hash) - lookup of LOCK structure
<A HREF="../../include/storage/lock.h">XIDLookupEnt</A> structure also address using transaction id, LOCK address. It is used to quickly
contains a pointer to the backend's PROC.lockQueue.</LI> check if the current transaction already has any locks on a table,
<LI><A HREF="../../include/storage/proc.h">Proc Header</A> - information rather than having to search through all the held locks. It also
about each backend, including locks held/waiting, indexed by process id</LI> stores the modes (read/write) of the locks held by the current
</UL> transaction. The returned <a
href="../../include/storage/lock.h">XIDLookupEnt</a> structure also
<P>Each data structure is created by calling <A contains a pointer to the backend's PROC.lockQueue.</li>
HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</A> and the
lookups are created by <A <li><a href="../../include/storage/proc.h">Proc Header</a> -
HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A></P> information about each backend, including locks held/waiting,
indexed by process id</li>
</ul>
<HR>
<SMALL> <p>Each data structure is created by calling <a
Maintainer: Bruce Momjian (<A href="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</a> and
HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR> the lookups are created by <a
Last updated: Mon Aug 10 10:48:06 EDT 1998 href="../../backend/storage/ipc/shmem.c">ShmemInitHash().</a></p>
</SMALL>
</BODY> <hr />
</HTML> <small>Maintainer: Bruce Momjian (<a
href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br />
Last updated: Fri May 6 14:22:27 EDT 2005</small>
</body>
</html>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment