From 224a62c5b793bcc6ddf7c3b8e6301e6c5fa23ee9 Mon Sep 17 00:00:00 2001 From: Bruce Momjian <bruce@momjian.us> Date: Tue, 21 Jul 1998 04:48:31 +0000 Subject: [PATCH] Update. --- src/tools/backend/index.html | 94 ++++++++++++++++++------------------ 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html index 51e4972037f..300061deae1 100644 --- a/src/tools/backend/index.html +++ b/src/tools/backend/index.html @@ -43,37 +43,35 @@ Click on an item to see more detail or look at the full <HR> <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 + +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</A> or <A -HREF="../../include/nodes/parsenodes.h">SelectStmt.</A> -<P> +<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</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> +<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 -<I>WHERE</I> clause qualification, which is filled in by -<A HREF="../../backend/parser/parse_clause.c">transformWhereClause().</A> +<I>WHERE</I> 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 -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> +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 @@ -82,18 +80,18 @@ HREF="../../include/nodes/primnodes.h">Resdom</A> entries, which are placed in <A HREF="../../include/nodes/parsenodes.h">target list entries,</I> and 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> +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> +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> +HREF="../../backend/rewrite">rewrite</A> system.<P> + The <A HREF="../../backend/optimizer">optimizer</A> takes the Query structure and generates an optimal <A @@ -101,45 +99,46 @@ 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(<I>WHERE</I> clause) to consider optimal index usage. -<P> +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> +children.<P> -There are many other modules that support this basic functionality. -They can be accessed by clicking on the flowchart. -<P> -<HR> -<P> +There are many other modules that support this basic functionality. They +can be accessed by clicking on the flowchart.<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 structures: + <UL> <LI>ShmemIndex - lookup shared memory addresses using structure names <LI><A HREF="../../include/storage/buf_internals.h">Buffer 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 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) - control structure for -each locking method. Currently, only multi-level locking is used(<A +<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) - 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 -HREF="../../include/storage/lock.h">LOCKTAG)</A>. The lock table structure contains the -lock modes(read/write or shared/exclusive) and circular linked list of backends (<A +HREF="../../include/storage/lock.h">LOCKTAG)</A>. The lock table +structure contains the lock modes(read/write or shared/exclusive) and +circular linked list of backends (<A HREF="../../include/storage/proc.h">PROC</A> structure pointers) waiting on the lock. <LI>MultiLevelLockTable (xid hash) - lookup of LOCK structure address @@ -152,11 +151,12 @@ contains a pointer to the backend's PROC.lockQueue. <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 lookups are created by -<A HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A> -<P> +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> -- GitLab