From b15e7df8c943225e1ae09ec500af9bcc21f6b779 Mon Sep 17 00:00:00 2001 From: Bruce Momjian <bruce@momjian.us> Date: Sun, 28 Jun 1998 16:35:41 +0000 Subject: [PATCH] backend update. --- src/tools/backend/index.html | 91 +++++++++++++++++------------------- 1 file changed, 44 insertions(+), 47 deletions(-) diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index dbf78042a46..7fe64404319 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -8,30 +8,30 @@ PostgreSQL Backend Flowchart </H1> <H2 ALIGN=CENTER> by Bruce Momjian -</H2 ALIGN=CENTER> +</H2> <P> -Queries come into the backend via data packets coming in through TCP/IP -and Unix Domain sockets. They are loaded into a string, and passed to +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 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-type-specific +identify the query type, and load the proper query-specific structure, like <A HREF="../../include/nodes/parsenodes.h">CreateStmt or SelectStmt.</A> <P> The query is then identified as a <I>Utility</I> function or a more -complex query. <I>Utility</I> queries are processed by a -query-type-specific function in <A HREF="../../backend/commands"> -commands.</A> Complex queries, like <I>SELECT, UPDATE,</I> and -<I>DELETE</I> require much more handling. +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 <B>SELECT, UPDATE,</B> and +<B>DELETE</B> requires much more handling. <P> -The parser takes the complex queries, and creates a +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 -WHERE clause qualification, which is filled in by +<B>WHERE</B> clause qualification, which is filled in by <A HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A> Each table referenced in the query is represented by a <A HREF="../../include/nodes/parsenodes.h"> RangeTableEntry,</A> and they @@ -39,73 +39,70 @@ 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. <P> -Certain queries, like SELECT, return columns of data. Other queries, -like INSERT and UPDATE, specify the columns modified by the query. -These column references are converted to <A -HREF="../../include/nodes/primnodes.h"> Resdom</A> entries, which are +Certain queries, like <B>SELECT,</B> return columns of data. Other +queries, like <B>INSERT</B> and <B>UPDATE,</B> specify the columns +modified by the query. These column references are converted to <A +HREF="../../include/nodes/primnodes.h">Resdom</A> entries, which are linked together to make up the <I>target list</I> of 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(SUM()), GROUP BY, ORDER BY are -also stored in their own Query fields. +Other query elements, like aggregates(<B>SUM()</B>), <B>GROUP BY,</B> +<B>ORDER BY</B> are also stored in their own Query fields. <P> -The next step is for the Query to be modified by any VIEWS or RULES that -may apply to the query. This is performed by the <A +The next step is for the Query to be modified by any <B>VIEWS</B> or +<B>RULES</B> 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> containing the -primitive operations to be performed by the executor to execute the -query. The <A HREF="../../backend/optimizer/path">path</A> module -determines the best table join order and join type of each table in the -RangeTable, using Query.qual(WHERE clause) to consider optimal index -usage. +structure and generates an optimal <A +HREF="../..//include/nodes/plannodes.h">Plan,</A> which contains the +operations to be performed to execute the query. The <A +HREF="../../backend/optimizer/path">path</A> module determines the best +table join order and join type of each table in the RangeTable, using +Query.qual(<B>WHERE</B> 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 -is returned to the client. +returned to the client. <P> -There are many other modules that support this basic functionality. +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, and backend information: <UL> -<LI>ShmemIndex - contains an index of all other shared memory -structures, allowing quick lookup of other structure locations in shared -memory +<LI>ShmemIndex - lookup of shared memory addresses using structure names <LI><A HREF="../../include/storage/buf_internals.h">Buffer -Descriptors</A> - control header for shared memory buffer block - -<LI><A HREF="../../include/storage/buf_internals.h">Buffer Blocks</A> -- block of table/index data shared by all backends -<LI>Shared Buf Lookup Table - lookup to see if a requested buffer -is already in the shared memory area -<LI><A HREF="../../include/storage/lock.h">LockTable</A> -- lock table structure, specifiying table, lock types, and -backends holding or waiting on lock -<LI>LockTable (lock hash) - lookup of LockTable structures using -table name +Descriptors</A> - control header for buffer cache block +<LI><A HREF="../../include/storage/buf_internals.h">Buffer Blocks</A> - +data/index buffer cache block +<LI>Shared Buf Lookup Table - lookup of buffer cache block address using +table name and block number(<A HREF="../../include/storage/buf_internals.h"> +BufferTag</A>) +<LI><A HREF="../../include/storage/lock.h">LockTable (ctl)</A> - lock table +structure, specifiying table, lock types, and backends holding or +waiting on lock +<LI>LockTable (lock hash) - lookup of LockTable structures using relation +and database object ids <LI>LockTable (xid hash) - lookup of LockTable structures using transaction id <LI><A HREF="../../include/storage/proc.h">Proc Header</A> - information about each backend, including locks held/waiting, indexed by process id </UL> Each data structure is created by calling <A -HREF="../../backend/storage/ipc/shmem.c"> ShmemInitStruct(),</A> and -the lookup hashes are created by +HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</A> and +the lookups are created by <A HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A> <HR> <CENTER> <EM><BIG> -Click on an item to see more detail or click -<A HREF="backend_dirs.html">here</a> to see the full index. -</EM></BIG> +Click on an item to see more detail or +<A HREF="backend_dirs.html">click</A> to see the full index. +</BIG></EM> <BR> <BR> -<IMG src="flow.jpg" usemap="#flowmap"> +<IMG src="flow.jpg" usemap="#flowmap" alt="flowchart"> </CENTER> <MAP name="flowmap"> <AREA COORDS="290,10,450,50" HREF="backend_dirs.html#main"> -- GitLab