projects
/
postgresql.git
/ commitdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
| commitdiff |
tree
raw
|
patch
| inline |
side by side
(parent:
7f61f8a
)
Update.
author
Bruce Momjian
Tue, 21 Jul 1998 04:48:31 +0000
(
04:48
+0000)
committer
Bruce Momjian
Tue, 21 Jul 1998 04:48:31 +0000
(
04:48
+0000)
src/tools/backend/index.html
patch
|
blob
|
blame
|
history
diff --git
a/src/tools/backend/index.html
b/src/tools/backend/index.html
index 51e4972037f4dff6974512824c27b0d605d935b9..300061deae1e37a8755af239c62565758d429e3c 100644
(file)
--- 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
-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
parser,
where the lexical scanner,
-
scan.l,
-breaks the query up into tokens(words). The parser
-uses
-
gram.y
and the tokens to
-identify the query type, and load the proper query-specific structure,
-like
CreateStmt
or
-HREF="../../include/nodes/parsenodes.h">SelectStmt.
-
+
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.
-
+
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().
+
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
-makeRangeTable(). Query.rtable holds the query's range table.
-
+are linked together to form the
range table
of the query, which
+
is
generated by
+makeRangeTable(). 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
@@
-82,18
+80,18
@@
HREF="../../include/nodes/primnodes.h">Resdom entries, which are
placed in
target list
entries, and linked together to make up the
target list
of
the query. The target list is stored in Query.targetList, which is
-generated by
-
transformTargetList().
>
-
+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.
-
+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.
-
+HREF="../../backend/rewrite">rewrite system.
+
The
optimizer
takes the Query
structure and generates an optimal
@@
-101,45
+99,46
@@
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.
-
+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.
-
+children.
-There are many other modules that support this basic functionality.
-They can be accessed by clicking on the flowchart.
-
-
-
+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 table recently used data/index
blocks, locks, backend 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(
-BufferTag)
-
MultiLevelLockTable (ctl) - control structure for
-
each locking
method. Currently, only multi-level locking is used(
+
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/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
@@
-152,11
+151,12
@@
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
-
ShmemInitHash().
>
-
+HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and
the
+lookups are created by
+
HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().
>
+