Update backend flowchard wording
authorBruce Momjian
Fri, 6 May 2005 18:23:13 +0000 (18:23 +0000)
committerBruce Momjian
Fri, 6 May 2005 18:23:13 +0000 (18:23 +0000)
src/tools/backend/index.html

index 6d85edfcf84a8fc181a8612f06cb0e6bdd53d1e0..4ca496924900e9235091bb70ab0770d87293f206 100644 (file)
-
-
-How PostgreSQL Processes a Query
-
-
-

-How PostgreSQL Processes a Query
-
-

-by Bruce Momjian
-
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Click on an item to see more detail or look at the full
-index.
-
-
-
-

-

-
-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
-parser, where the lexical scanner,
-scan.l, breaks the query up
-into tokens(words).  The parser uses 
-HREF="../../backend/parser/gram.y">gram.y and the tokens to identify
-the query type, and load the proper query-specific structure, like 
-HREF="../../include/nodes/parsenodes.h">CreateStmt or 
-HREF="../../include/nodes/parsenodes.h">SelectStmt.

-
-
-The query is then identified as a Utility query or a more complex
-query.  A Utility query is processed by a query-specific function
-in  commands. A complex query, like
-SELECT, UPDATE, and DELETE requires much more handling.

-
-
-The parser takes a complex query, and creates a
-Query structure that
-contains all the elements used by complex queries.  Query.qual holds the
-WHERE clause qualification, which is filled in by 
-HREF="../../backend/parser/parse_clause.c">transformWhereClause().
-Each table referenced in the query is represented by a 
-HREF="../../include/nodes/parsenodes.h"> RangeTableEntry, and they
-are linked together to form the range table of the query, which
-is generated by 
-transformFromClause().  Query.rtable holds the query's range table.

-
-
-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 
-HREF="../../include/nodes/primnodes.h">TargetEntry entries, which are
-linked together to make up the target list of
-the query. The target list is stored in Query.targetList, which is
-generated by 
-HREF="../../backend/parser/parse_target.c">transformTargetList().

-
-
-Other query elements, like aggregates(SUM()), GROUP BY,
-and ORDER BY are also stored in their own Query fields.

-
-
-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 
-HREF="../../backend/rewrite">rewrite system.

-
-
-The optimizer takes the Query
-structure and generates an optimal 
-HREF="../../include/nodes/plannodes.h">Plan, which contains the
-operations to be performed to execute the query.  The 
-HREF="../../backend/optimizer/path">path 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.

-
-
-The Plan is then passed to the 
-HREF="../../backend/executor">executor 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.

-
-There are many other modules that support this basic functionality. They
-can be accessed by clicking on the flowchart.

-
-
-

-
-
-Another area of interest is the shared memory area, which contains data
-accessable to all backends.  It has recently used data/index blocks,
-locks, backend process information, and lookup tables for these
-structures:
-

-
-
     
-
  • ShmemIndex - lookup shared memory addresses using structure names
  • -
  • Buffer
  • -Descriptor - control header for buffer cache block
    -
  • Buffer Block -
  • -data/index buffer cache block
    -
  • Shared Buffer Lookup Table - lookup of buffer cache block addresses
  • -using table name and block number(
    -HREF="../../include/storage/buf_internals.h"> BufferTag)
    -
  • MultiLevelLockTable (ctl) - control structure for each locking
  • -method.  Currently, only multi-level locking is used(
    -HREF="../../include/storage/lock.h">LOCKMETHODCTL).
    -
  • MultiLevelLockTable (lock hash) - the 
    -HREF="../../include/storage/lock.h">LOCK structure, looked up using
    -relation, database object ids(
    -HREF="../../include/storage/lock.h">LOCKTAG).  The lock table
    -structure contains the lock modes(read/write or shared/exclusive) and
    -circular linked list of backends (
    -HREF="../../include/storage/proc.h">PROC structure pointers) waiting
    -on the lock.
  • -
  • MultiLevelLockTable (xid hash) - lookup of LOCK structure address
  • -using transaction id, LOCK address.  It is used to quickly check if the
    -current transaction already has any locks on a table, rather than having
    -to search through all the held locks.  It also stores the modes
    -(read/write) of the locks held by the current transaction.  The returned
    -XIDLookupEnt structure also
    -contains a pointer to the backend's PROC.lockQueue.
    -
  • Proc Header - information
  • -about each backend, including locks held/waiting, indexed by process id
    -
    -
    -

    Each data structure is created by calling 

    -HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and the
    -lookups are created by 
    -HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().

    -
    -
    -
    -
    -Maintainer:    Bruce Momjian (
    -Last updated:      Mon Aug 10 10:48:06 EDT 1998
    -
    -
    -
    +
    +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    +
    +
    +
    +content="HTML Tidy for BSD/OS (vers 1st July 2002), see www.w3.org" />
    +How PostgreSQL Processes a Query
    +
    +
    +vlink="#A00000" alink="#0000FF">
    +

    How PostgreSQL Processes a Query

    +
    +

    by Bruce Momjian

    +
    +

    +
    +Click on an item to see more detail or look at the full
    +index.
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +

    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 parser, where the
    +lexical scanner, scan.l,
    +breaks the query up into tokens(words). The parser uses 
    +href="../../backend/parser/gram.y">gram.y and the tokens to
    +identify the query type, and load the proper query-specific
    +structure, like 
    +href="../../include/nodes/parsenodes.h">CreateStmt or 
    +href="../../include/nodes/parsenodes.h">SelectStmt.

    +
    +

    The statement is then identified as complex (SELECT / INSERT /

    +UPDATE / DELETE) or a simple, e.g  CREATE USER, ANALYZE, ,
    +etc.  Utility commands are processed by statement-specific functions in 
    +href="../../backend/commands">backend/commands. Complex statements
    +require more handling.

    +
    +

    The parser takes a complex query, and creates a 

    +href="../../include/nodes/parsenodes.h">Query structure that
    +contains all the elements used by complex queries. Query.qual holds
    +the WHERE clause qualification, which is filled in by 
    +href="../../backend/parser/parse_clause.c">transformWhereClause().
    +Each table referenced in the query is represented by a 
    +href="../../include/nodes/parsenodes.h">RangeTableEntry, and
    +they are linked together to form the range table of the
    +query, which is generated by 
    +href="../../backend/parser/parse_clause.c">transformFromClause().
    +Query.rtable holds the query's range table.

    +
    +

    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 
    +href="../../include/nodes/primnodes.h">TargetEntry entries,
    +which are linked together to make up the target list of the
    +query. The target list is stored in Query.targetList, which is
    +generated by 
    +href="../../backend/parser/parse_target.c">transformTargetList().

    +
    +

    Other query elements, like aggregates(SUM()), GROUP

    +BY, and ORDER BY are also stored in their own Query
    +fields.

    +
    +

    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 rewrite
    +system.

    +
    +

    The optimizer takes the

    +Query structure and generates an optimal 
    +href="../../include/nodes/plannodes.h">Plan, which contains the
    +operations to be performed to execute the query. The 
    +href="../../backend/optimizer/path">path 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.

    +
    +

    The Plan is then passed to the 

    +href="../../backend/executor">executor 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.

    +
    +

    There are many other modules that support this basic

    +functionality. They can be accessed by clicking on the
    +flowchart.

    +
    +
    +

    Another area of interest is the shared memory area, which

    +contains data accessable to all backends. It has recently used
    +data/index blocks, locks, backend process information, and lookup
    +tables for these structures:

    +
    +
      +
    • ShmemIndex - lookup shared memory addresses using structure
    • +names
      +
      +
    • Buffer
    • +Descriptor - control header for buffer cache block
      +
      +
    • Buffer
    • +Block - data/index buffer cache block
      +
      +
    • Shared Buffer Lookup Table - lookup of buffer cache block
    • +addresses using table name and block number( 
      +href="../../include/storage/buf_internals.h">BufferTag)
      +
      +
    • MultiLevelLockTable (ctl) - control structure for each locking
    • +method. Currently, only multi-level locking is used(
      +href="../../include/storage/lock.h">LOCKMETHODCTL).
      +
      +
    • MultiLevelLockTable (lock hash) - the 
      +href="../../include/storage/lock.h">LOCK structure, looked up
      +using relation, database object ids(
      +href="../../include/storage/lock.h">LOCKTAG). The lock table
      +structure contains the lock modes(read/write or shared/exclusive)
      +and circular linked list of backends (
      +href="../../include/storage/proc.h">PROC structure pointers)
      +waiting on the lock.
    • +
      +
    • MultiLevelLockTable (xid hash) - lookup of LOCK structure
    • +address using transaction id, LOCK address. It is used to quickly
      +check if the current transaction already has any locks on a table,
      +rather than having to search through all the held locks. It also
      +stores the modes (read/write) of the locks held by the current
      +transaction. The returned 
      +href="../../include/storage/lock.h">XIDLookupEnt structure also
      +contains a pointer to the backend's PROC.lockQueue.
      +
      +
    • Proc Header -
    • +information about each backend, including locks held/waiting,
      +indexed by process id
      +
      +
      +

      Each data structure is created by calling 

      +href="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and
      +the lookups are created by 
      +href="../../backend/storage/ipc/shmem.c">ShmemInitHash().

      +
      +
      +Maintainer: Bruce Momjian (
      +
      +Last updated: Fri May  6 14:22:27 EDT 2005
      +
      +