File: overview.html

package info (click to toggle)
pgadmin3 1.4.3-2
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 29,796 kB
  • ctags: 10,758
  • sloc: cpp: 55,356; sh: 6,164; ansic: 1,520; makefile: 576; sql: 482; xml: 100; perl: 18
file content (116 lines) | stat: -rw-r--r-- 6,190 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter41.Overview of PostgreSQL Internals</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="internals.html" title="PartVII.Internals">
<link rel="prev" href="internals.html" title="PartVII.Internals">
<link rel="next" href="connect-estab.html" title="41.2.How Connections are Established">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" lang="en" id="overview">
<div class="titlepage"><div><div><h2 class="title">
<a name="overview"></a>Chapter41.Overview of PostgreSQL Internals</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="overview.html#query-path">41.1. The Path of a Query</a></span></dt>
<dt><span class="sect1"><a href="connect-estab.html">41.2. How Connections are Established</a></span></dt>
<dt><span class="sect1"><a href="parser-stage.html">41.3. The Parser Stage</a></span></dt>
<dd><dl>
<dt><span class="sect2"><a href="parser-stage.html#id815181">41.3.1. Parser</a></span></dt>
<dt><span class="sect2"><a href="parser-stage.html#id815385">41.3.2. Transformation Process</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="rule-system.html">41.4. The <span class="productname">PostgreSQL</span> Rule System</a></span></dt>
<dt><span class="sect1"><a href="planner-optimizer.html">41.5. Planner/Optimizer</a></span></dt>
<dd><dl><dt><span class="sect2"><a href="planner-optimizer.html#id815662">41.5.1. Generating Possible Plans</a></span></dt></dl></dd>
<dt><span class="sect1"><a href="executor.html">41.6. Executor</a></span></dt>
</dl>
</div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Author</h3>
<p>    This chapter originated as part of
    [<a href="biblio.html#sim98" title="[sim98]">sim98</a>], Stefan Simkovics'
    Master's Thesis prepared at Vienna University of Technology under the direction
    of O.Univ.Prof.Dr. Georg Gottlob and Univ.Ass. Mag. Katrin Seyr.
   </p>
</div>
<p>   This chapter gives an overview of the internal structure of the
   backend of <span class="productname">PostgreSQL</span>.  After having
   read the following sections you should have an idea of how a query
   is processed. This chapter does not aim to provide a detailed
   description of the internal operation of
   <span class="productname">PostgreSQL</span>, as such a document would be
   very extensive. Rather, this chapter is intended to help the reader
   understand the general sequence of operations that occur within the
   backend from the point at which a query is received, to the point
   at which the results are returned to the client.
  </p>
<div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="query-path"></a>41.1.The Path of a Query</h2></div></div></div>
<p>    Here we give a short overview of the stages a query has to pass in
    order to obtain a result.
   </p>
<div class="procedure"><ol type="1">
<li><p>      A connection from an application program to the <span class="productname">PostgreSQL</span>
      server has to be established. The application program transmits a
      query to the server and waits to receive the results sent back by the
      server.
     </p></li>
<li><p>      The <em class="firstterm">parser stage</em> checks the query
      transmitted by the application
      program for correct syntax and creates
      a <em class="firstterm">query tree</em>.
     </p></li>
<li>
<p>      The <em class="firstterm">rewrite system</em> takes
      the query tree created by the parser stage and looks for
      any <em class="firstterm">rules</em> (stored in the
      <em class="firstterm">system catalogs</em>) to apply to 
      the query tree.  It performs the
      transformations given in the <em class="firstterm">rule bodies</em>.
     </p>
<p>      One application of the rewrite system is in the realization of
      <em class="firstterm">views</em>.
      Whenever a query against a view
      (i.e. a <em class="firstterm">virtual table</em>) is made,
      the rewrite system rewrites the user's query to
      a query that accesses the <em class="firstterm">base tables</em> given in
      the <em class="firstterm">view definition</em> instead.
     </p>
</li>
<li>
<p>      The <em class="firstterm">planner/optimizer</em> takes
      the (rewritten) query tree and creates a 
      <em class="firstterm">query plan</em> that will be the input to the
      <em class="firstterm">executor</em>.
     </p>
<p>      It does so by first creating all possible <em class="firstterm">paths</em>
      leading to the same result. For example if there is an index on a
      relation to be scanned, there are two paths for the
      scan. One possibility is a simple sequential scan and the other
      possibility is to use the index. Next the cost for the execution of
      each path is estimated and the cheapest path is chosen.  The cheapest
      path is expanded into a complete plan that the executor can use.
     </p>
</li>
<li><p>      The executor recursively steps through
      the <em class="firstterm">plan tree</em> and
      retrieves rows in the way represented by the plan.
      The executor makes use of the
      <em class="firstterm">storage system</em> while scanning
      relations, performs <em class="firstterm">sorts</em> and <em class="firstterm">joins</em>,
      evaluates <em class="firstterm">qualifications</em> and finally hands back the rows derived.
     </p></li>
</ol></div>
<p>    In the following sections we will cover each of the above listed items
    in more detail to give a better understanding of <span class="productname">PostgreSQL</span>'s internal
    control and data structures.
   </p>
</div>
</div></body>
</html>