CISC 322 Assignment 1 Conceptual Architecture of PostgreSQL ...

pridefulauburnData Management

Dec 16, 2012 (4 years and 8 months ago)

145 views




CISC 322

Assignment 1

Conceptual Architecture of
PostgreSQL

October 22

2010













S
-
Queue
-
L

Adam Abu Hijleh
(8haa@queensu.ca)

Adam Ali (2aa13@queensu.ca)

Khurrum Abdul Mujeeb (7mka2@queensu.ca)

Stephen McDonald (8sjm3@queensu.ca)

Wissam Zaghai (
8wz1@queensu.ca
)






S
-
Q u e u e
-
L


P a g e
|
1



Table of Contents

Table of Contents………
…………………………………………………………………….…...1

Abstract………………
………………………………………………………………….…….….2

Introduction and Overview
……………………………………………………………...…..……3

Derivation Process……..
………………………………………………………………...….……4

Sources & Research Met
hods………………………………………………………….……….4

Initial Architectural I
deas…………………………………………………………
.…………...
4

Final Hypothesis…
………………....….……………………………...……………..................
4

Final Conceptual Architectu
re Design……………………………………………………….......
5

Diagram of Conceptual Archit
ecture…………………………………………………………..
5

Subsystem Functionali
ty……………………………………………………………
……………
6

Client
-
Interface Lib
rary…………………………………………………………………...…...
6

Postgres Back
-
End………………………………
……………………………………………..
6

Query Reques
t……………………………………………………………………………....
6


Parser Stage
…………………………………………………………………………….
6


Rewrite Quer
y…………………………………………
……………………………….
7


Planner/Optimi
zer……………………………………………………………………...
7


Executor……………………………………………………
…………………………..
7

Utilities……
………………………………………………………………………………...
8


Catalog Man
ager……………………………………………………………………….
8


Statistics……
…………………………………………………………………………
. 8


Access Metho
ds………………………………………………………………..……...
8


Nodes Li
st
…………………………………………………………………………….. 8


Storage Mana
ger………
……………………………………………………………....…
.
....
.8


Lock Manag
er………………………………………………………………………….
8


Buffer Man
ag
er………………………………………………………………………...
8


IPC…………………
………………………………....…………………………….….
8


Page Manage
r…………………………………………………………………………
.
8


File Manager………………………………
………………………………………...
…8


Disk Man
ager………………………………………………………………….…..
…..8

Concurrency Control and Thr
eading…………………………………………………………….9

Use Case
s………………
………………………………………………………………………..10

Complex Query………
………………………………………………………………………...10

Simple Query…………………………
………………………………………………………..11

Design Trade
-
offs……
…………………………………………………………………………..12

Reliability vs. Perfor
mance……………………………………………………………………
12


Scalability vs. Maintainabi
lity.………………………………………………………………...
12

Security vs. Perfor
mance………………………………………………………………………
12

Conclusions…
……………………………………………………………………………………
12

Limitations & Lessons Lea
rned……………………………………………………………….…12

Glossary……………
…………………………………………………
………………………….13

References…………
…………………………………………………………………………….14





S
-
Q u e u e
-
L


P a g e
|
2



Abstract


In this report we present an analysis of the
PostgreSQL
database management system. The
objective of this project was to determine a conceptual architecture for
PostgreSQL
through the
evaluation of available documentation pertaining to the system. Through our research we
determined the overall architecture to be
layered
, with a pipe and filter in the back end for query
processing
. This report includes an in
-
depth descript
ion of
PostgreSQL
subsystems and their
f
unctionalities, as well as two
diagrammed use cases that trace common functions through
depictions of system dependencies and the flow of data. This project will later assist in the
completion of a concrete architec
ture of
PostgreSQL
.




































S
-
Q u e u e
-
L


P a g e
|
3



Introduction and Overview


The purpose of this report is to give a detailed account of our overall process and findings
pertaining to the
PostgreSQL
conceptual architecture. First, a
general introduction to
PostgreSQL
,
an
overview of
its history, some real
-
world users, advantages and disadvantages
from both a “user” and “architectural” perspective, and a quick glance at some
PostgreSQL

features will be covered. We will then step thro
ugh our derivation process by examining
sources and methods used along with some of our early architectural interpretations, before
introducing our final conceptual architecture. A diagram of the final architecture will be shown,
with all dependencies vis
ible. Next, an in
-
depth view of the subsystems present in
PostgreSQL

will be presented. Examples of functionality will be depicted in our two use cases.
Following
our use cases, an analysis of design tradeoffs will be suggested. The paper will wrap up w
ith a
conclusion of our findings, our lessons learned and our limitations.


PostgreSQL
is a cross
-
platform
, open
-
source object
-
relational database management system with
a reputation for reliability, integrity, and correctness. It evolved from the “Ingre
s” project started
at UC Berkeley, officially becoming “
PostgreSQL
” in 1996.
No one company owns
PostgreSQL
,
but
rather a
n unincorporated association
of volunteers and companies share code
under a license.
The official
PostgreSQL
webpage cites their system as being advantageous due
to its low cost (from lack of licensing costs and low maintenance expenses), reliability, cross
-
platform nature, and extensibility
. It is considered to be “feature rich [and] standards
-
compliant”
by its
developers
(
P o s t g r e S QL
F AQ P a g e, 2 0 1 0 )
.

B o a s t i n g a n a b u n d a n t a r r a y o f f e a t u r e s,
i n c l u d i n g b u t n o t l i mi t e d t o Mu l t i Ve r s i o n C o n c u r r e n c y C o n t r o l ( MVC C ), p o i n t i n t i me
r e c o v e r y, o n l i n e/h o t b a c k u p s a n d a s o p h i s t i c a t e d q u e r y p l a n n e r/o p t i mi z e r, i t i s n o s u r p r i
s e t h i s
s y s t e m i s u t i l i z e d b y l a r g e c o mp a n i e s s u c h a s Ya h o o, My S p a c e, a n d S k y p e.

P o s t g r e S QL
p r o v i d e s h i g h s c a l a b i l i t y wi t h r e g a r d
s
t o t h e s h e e r q u a n t i t y o f d a t a i t c a n ma n a g e
a n d t h e n u mb e r o f c o
n c u r r e n t u s e r s i t c a n s u p p o r t. T h i s a l l o ws t h e d a t a b a s e t o
e x p a n d mo r e
s e a ml e s s l y, a n i mp o r t a n t f a c t o r f o r a n y c o mp a n y wi t h a g r o wi n g u s e r b a s e.
I t s e x t e n s i b i l i t y
a l l o ws f o r a l a r g e r a n g e o f c u s t o mi z a b i l i t y, s t e mmi n g f r o m
i t s o p e n s o u r c e n a t u r e c o u p l e d wi t h
i t s n o
-
s t r i n g s
-
a t t a c h e d l i c e n s e.

P o s t g r e S QL
also
r uns st or ed pr ocedur es i n
mor e t han
a dozen
l anguages, as wel l as suppor t i ng
many l i br ar y
i nt er f aces, whi ch
al l ows var i ous l anguages t o
i nt er f ace wi t h t he syst em.


Ther e ar e obvi ous
advant ages and di sadvant ages f r om an ar chi t ect ur al st andpoi nt
f or
Post gr
eSQL
. On one hand,
PostgreSQL
features a flexible catalog system and a client
-
server
model nicely adapted for applications requiring specialized data manipulation. It also has the
ability to determine whether an incoming query is simple or complex, which
cuts down on
runtime for queries not requiring complex handling. On the other hand,
PostgreSQL
has a
centralized distribution, requiring all storage devices to attach to a common CPU.


PostgreSQL
has an interesting process of evolution. Due to the license, anybody can work to
evolve or change the software at any point in time, for their own personal or business use.
Updates occur constantly, with a major update occurring approximately every year.
There is a
controlling group that decides what the major developments are for the mainstream
PostgreSQL
.
Proposals are sent into this controlling group, and they decide what to add or change. The
advantage of this is obvious;
PostgreSQL
can become much
tailored to a particular need. The


S
-
Q u e u e
-
L


P a g e
|
4



mainstream software however, may not evolve quickly because a group from different
com
panies must decide on changes, and does not ha
ve a particular name tied to it.



Derivation Process


Sources and Research Methods


In
order to devise our own conceptual architecture of
PostgreSQL
, lots of research had to be
done.
The
PostgreSQL
manual provided a great amount of information that helped further our
understanding. Other sources we looked at include the
PostgreSQL
Developers Guide and the

PostgreSQL
Wiki page.
Once enough research was done, we felt that we had enough material to
help us derive the architecture style of
PostgreSQL
.


In the process of determining

this architecture
, we were able to determine relationships and
dependencies in
-
between components within the system. This was crucial for us, as we needed to
understand the complete structure of
the system in order to create an accurate
conceptual
architecture.


The backb
one of our conceptual architecture was the reference architecture found on the course’s
website. The reference architecture was a great visual explanation as to how database
management systems work, and what their main components are. Various conceptual
ar
chitectures for
PostgreSQL
were found online, and that too helped in devising our conceptual
architecture.


For unclear
terms, components and structure definitions and explanation, we visited
Wikipedia
,
which
we thought
was a great help in this project as
we were able to find all information and
diagrams needed to understand material better.


Initial Hypothesis


Our initial hypothesis regarding the inherent top
-
level conceptual architecture of
PostgreSQL
led
us to believe that it was

a client
-
server based
architecture. However, discussion in class
and
between group members
made us realize that
o
ur initial hypothesis was wrong
. Although certain
features of a client
-
server based architecture are intrinsic to how connections are established
between the user a
nd the
PostgreSQL
database, the overall internal architecture is more complex.


Final Hypothesis


In order to fully conceptualize the architecture of
PostgreSQL
, we needed to look deeper into the
backend server processes. Our approach was to examine t
he individual subcomponents and the
relationship between each component, noting any layers of abstraction, data flow and control
flow. When looking at the individual subsystems, we uncovered various layers of abstraction as
we traced data/control flow fr
om the front end to the back end.
Therefore, w
e would like to
propose a layered architecture as our final
PostgreSQL
hypothesized architecture.




S
-
Q u e u e
-
L


P a g e
|
5



The top most
layer
is the User Interface layer, which in our diagram is represented as
the
Front
End. The
main function of this layer is to translate user commands into something the
machine

can understand. The next layer beneath the US layer is the Logic layer. This layer processes
commands, makes logical decisions and evaluations and performs calculations.
It also moves
and processes data between the two surrounding layers. Lastly, the final layer of our layered
architecture is the Data tier. In this layer, information is stored and retrieved from a database or
file system. The information is then passe
d back to the log
ic layer for processing and eventually
passed
back to the user.


By mapping components of the reference architecture onto our understanding of the
PostgreSQL

system, we were able to conceive our first prototype of the conceptual architecture
.


Figure 1. The above diagrams illustrate the mapping of the reference architecture (left) to the subsystem and
component architecture (right).


Final Conceptual
Architecture Hypothesis




 
 
 
 
Figure 2. This figure illustrates
a layered
conceptual
architecture of Po
stgreSQL.
Data flow and
control is
between adjacent layers. The
Client Manager Layer (Front
End) is the most abstract layer.
The logic layer is the Postgres
server (Back End) and the
lowest layer is the Storage
manager and shared utilities.



S
-
Q u e u e
-
L


P a g e
|
6




Subsystem Functionality


Front End:
Client
and Library
Interface


A “process per user” client/server is applied in
PostgreSQL
as the main model. At all times, there
is one client process connected to only one server. A master process is used in order to spawn
new servers whenever a new conn
ection is established. The master process is needed, as we do
not know how many connections will be made at a given period of time or day. The master
process is also known as postgres. Communication is held between server tasks using shared
memory and sema
phores in order to ensure data integrity throughout concurrent data access.

The
client process could be any program in which understands
PostgreSQL
protocol. The majority of
the clients are based on the language C’s library libpq. Other implementations are
available such
as the JAVA JDBC driver.



After a connection has been established between the client and the server, the client process can
send a query to the server (backend). The query is sent as a plain text format, and there is no
parsing carried out
in the client process (front end). The query is taken care of in the back end,
and once processed, it is transmitted back to the client over the established connection, which is
shut off once the user is done (logged off).


Back
-
End: Query Engine


Parser
Stage


The parser stage is split into two parts: the parser and the transformation process. The parser
checks the query string for valid syntax. If the syntax is valid, a parse tree is built, if not, an
error is returned. The parser is split into two pa
rts; the lexer and the parser. The lexer
recognizes identifie
r
s
(SQL keywords, et cetera) and creates a token
for each
that is then handed
to the parser. It is defined in the file scan.l (located in the File Manager within the Storage
Manager) which is t
ransformed into a C source file by the program flex (a Unix tool). The parser
contains a set of grammar rules and actions that are performed whenever a rule is fired. It is
defined in the file gram.y (located in the File Manager within the Storage Manager
), and is
turned into a C source file by the program bison (another Unix tool). After both files are readily
available as C source files, a normal C compiler can be used to create the parser.
The parser
creates a parse tree that is passed forward to the tr
ansformation process.


Since the parser only performs syntactical analysis, there is no way to determine the semantics of
the requested operation,
and
thus the need for the transformation process.
The transformation
process completes the semantic interpre
tation, required to distinguish which tables, functions and
operators are referenced by the query.
The
catalog manager
is accessed for reference during this
process.
The resulting data structure to embody this information is called a query tree.


It is
necessary to split the Parser Stage into two parts in order to ensure that an entered query
string is actually a query. Analyzing syntactic structure first will identify transaction control


S
-
Q u e u e
-
L


P a g e
|
7



commands that can be executed without further analysis. When it i
s clear that the query string is
a real query, a transaction is safe to begin.


Rewrite Query


The
query
rewrite system is a module that exists between the parser stage and the
planner/optimizer. It modifies the query tree handed back by the parser stage, which represents a
user query, by looking for the designer’s rules, which are in the system catalogs. It
then passes
the modified query to the query planner for planning and execution. If there are no rules, then the
tree is not re
-
written. If there are rules present that have to be applied to the query then it rewrites
the tree to an alternate form.


Planne
r/Optimizer


The planner/optimizer accepts as its input a parsed and rule augmented query tree. The output
structure is a tree of plan nodes. The nodes at the leaf level of the tree are simple scan nodes that
return raw rows from a table. If the query re
quires more complex operations, there will be
additional nodes above the scan nodes to perform those operations.


The primary task of the planner/optimizer is to deduce an optimal execution plan for a given
SQL query. If the request is simple enough then it is computationally feasible for the planner to
exhaustively examine every possible execution plan and select th
e one that is most efficient.
Efficiency is usually measured in the number of disk page fetches. More complex queries, with
upper nodes, require more disk page fetches as the cost of upper nodes includes the cost of all of
its simple query children.


In order to select the most efficient plan of execution, the planner/optimizer needs to consult the
PostgreSQL
Statistics Collector and cost estimation
functions.
The Statistics Collector provides
the planner/optimizer with the necessary information about each table referenced by a particular
query such as the table location, the number of rows in that table and any particular indexes
belonging to that table. The
Statistics Collector is a part of the
PostgreSQL
Catalog Manager
under pg_statistic. Cost estimation functions are also contained within the System Catalog
Manager under pg_am. When called, it returns estimates of the cost of accessing the desired
index
. Once the most efficient plan is chosen, control is sent to the Executor where the most
efficient plan is then executed.


Executor


The Executor receives the plan created by the planner/optimizer and recursively processes it to
extract the required set of
rows and sends this data to the client
.
This execution is done using the
parse tree that contains the plan to process a given complex query. Each node on a parse tree
contains steps to solve the query, unless the left and right children of a given node ar
e not empty,
the executor recursively calls itself with each child. Until the children of a node are empty, the
same conditions would apply further down the tree as well. Once the parse tree encounters a null,
the processes on the tree are performed from t
he bottom of the tree till the top and the result is
sent up to the client.



S
-
Q u e u e
-
L


P a g e
|
8




Back
-
End: Utilities



The query process (i.e. the back
-
end of the system) utilizes various components and utilities
provided by shared components available on
PostgreSQL
.

The
components of these utilities are:

o

General Utilities
: All the sub
-
components of the back
-
end make use of these utilities;
they consist of operations such as various initializing & error reporting. It also behaves as
a memory manager; regulating memory for
the back
-
end of the system.

o

Access Methods
: Controls the way data is accessed in heaps, indexes and transactions in
the back
-
end

o

Nodes/Lists:
PostgreSQL
stores information about SQL queries in Nodes and these
Nodes are stored within a List, behaving much l
ike a linked list structure. Nodes and
Lists are used by the parser, planner/optimizer and executor sub
-
components of the back
-
end to store requests and data

o

Catalog:
A critical utility used towards the functionality of the back
-
end. It contains
functions
that manipulate system tables and catalogs, it is called up by various sub
-
components of the back
-
end for references regarding the current query being processed
by the query processor

Back
-
End: Storage Manager


The storage system is an important component
that allows data access to the back end. Its main
function is to regulate access to the file manager, provide shared memory and buffers and to
maintain a means of communication between multiple processes on a single machine. We were
able to map all the su
bcomponents of the Storage system from the architecture to our conceptual
architecture.


The storage system consists of several subcomponents:


o

File Manager:
Component that’s in charge of managing file systems. All data files are
in the file system, so if
any component from the Server needs to access this data, it must
access this subcomponent.

o

Inter
-
process
communication
:
A set of mechanisms that facilitate
communications and
data sharing between multiple processes.

o

Lock Manager:
A process that provides locks to achieve consistency and to prevent read
and write collision.

o

Buffer Manager:
provide
s management of shared buffers.

o

Page Manager
: manages pages by
using the ‘Least Recently used’ algorithm.

o

Disk Manager
: interacts with the physical memory of the server.




S
-
Q u e u e
-
L


P a g e
|
9



Many of these components are dependent on each other. For instance, the buffer manager, page
manager and file manager all dependent on the disk man
ager and the p
hysical storage available
and vice versa. The management of buffers is
dependent on the lock manager (
in case a client is
trying
to read to a file tha
t is being written for instance), and the IPC. The IPC depends on the
buffer manager, which
would manage data sharing depending on the data that is being shared.




Figure
3



The above diagram illustrates the dependencies between the components of the

storage manager


Concurrency Control and Threading


Although
PostgreSQL
implements a single server process per client request, multiple client
-
server requests may be established concurrently. The Postgres server listens at a specified
TCP/IP port for any incoming connections and spawns a new server process each time a valid
request is made. In order to process concurrent query transactions,
PostgreSQL
implements a
multi
-
version concurrency control mechanism as well as table level locks.


In multi version concurrency control, each transaction sees a “snapshot” view of the d
atabase
when it is initiated. This is done via the use of a transaction ID to determine what state of the
DB to read. This mechanism ensures that data remains consistent throughout the duration of the
transaction and other users of the database will not s
ee any changes made until the transaction
has been committed. Multi version currency control only locks individual records rather than
and entire table. If one wishes to lock and entire table, table level locks are required. For
example, if one wished t
o alter a table, this transaction cannot be executed concurrently with
other operations on the same table, thus a table lock needs to be initiated.


A drawback of using table level locks that that it increases the likelihood of deadlocks, wherein
two or
more transactions hold locks that the other wants. Although
PostgreSQL
detects and
resolves deadlocks when they occur, they still cause a slight decrease in performance.







S
-
Q u e u e
-
L


P a g e
|
10





Use C
ase

:
Complex Select Query

Figure
4



The above
use case
diagram illustrates the sequence of
events that occur when a select query
is made by the Front End.


F
igure 1 exemplifies a select query as processed by
PostgreSQL
. Initially, the user requests to
log
in to the P
ostgres
server; the client sends this request to the interface. Once the user is logged
in, the interface requests a server space and a communication channel to be established for the
user. Now that the user has access to a designated server, a select query is se
nt to that same
server. The server receives this query and sends it to the parser, which looks up grammar rules
(syntax) and actions from the storage manager, forming a parse tree for the select query. Once
the tree has been constructed, it is then sent to
the transformation process in which checks the
semantics of the parse tree. Now, the rewriter has to modify the tree according to rules that are
looked up in the storage manager and functions from the catalog manager. This newly modified
tree is sent to t
he planner/optimizer so that the most efficient method of execution can be
determined. This is decided by looking at the statistics of the tree found in the catalog manager.
As we now have a way to execute the query efficiently, the tree is sent off to the
executor
that

 
 
 


S
-
Q u e u e
-
L


P a g e
|
11



accesses the storage manager to retrieve and modify records. After the tree has been executed, it
is sent back through the server, interface, and client before eventually reaching the user.


Use Case: Simple
Create Table
Query


Figure
5



The above use case diagram illustrates the sequence of events that occur when a select query is made by
the Front End.

The use case in figure 5
illustrates a create table query as processed by
PostgreSQL
. Initially, the
user requests to log
in to the P
os
tgres server; the client sends this request to the interface. Once
the user is logged in, the interface requests a server space and a communication channel to be
established for the user. Now that the user has access to a designated server, a select query
is sent
to that same server. The server receives this query and sends it to the parser, which looks up
grammar rules (syntax) and actions from the storage manager, forming a parse tree for the select
query. Once the tree has been constructed, it is then se
nt to the transformation process in which
checks the semantics of the parse tree. After that, the transformation process calls lower level


S
-
Q u e u e
-
L


P a g e
|
12



functions from the utility manager. In return, after the functions have been called, the table is
created and sent to
the storage manager to be stored. The storage manager then returns that
output (executed query)
to the user through the server
interface then
to
the client
.

Design Trade
-
Offs


Like all databases,
PostgreSQL
strives to be reliable and it does this by implementing techniques
to ensure data integrity. For instance, data is currently being updated safely in storage and so any
problem with the server will not affect any of the files.


Another procedure known as W
rite
-
ahead logging ensures that even if the database where to
crash during changes to a file, data can be easily recovered. This procedure also supports on
-
line
backup and point
-
time recovery and is an integral part of many database systems. These safe
pra
ctices that make
PostgreSQL
a very reliable program sacrifice performance since more work
needs to be done and thus more time is used.


PostgreSQL
is a scalable system, since the server is large and powerful and can handle multiple
clients at the same tim
e. While this is very costly, this can actually improve performance since
we have such powerful hardware that can satisfy every client’s need. However, this impairs
maintainability since the whole system needs to be taken down in order to repair a simple
defect.

PostgreSQL
is also known for its security; clients aren’t allowed access to important
subcomponents of the Storage manager or Utilities. This also limits performance, as more effort
is needed to maintain security.


Conclusions


Overall, we found that at its highest level,
PostgreSQL
has a layered architecture with three main
layers. These layers are: client and library interface, a server, which consists of a pipe
-
filter
architecture style, and a storage manager and utilities man
ager. We came to this conclusion after
researching extensively and relating our findings with the reference architecture. Through this
research we found that
PostgreSQL
had a good reputation for being a very reliable and secure
database system, taking many
measures to protect data and prevent any crashes.

Limitations & Lessons Learned


Through the course of our research, we came across the following limitations:

o

Lack of personal experience with
PostgreSQL
, databases in general, and no previous
experience de
riving software architecture.

o

Incomplete and conflicting sources; sources didn’t always have dates or version
numbers, making it difficult to determine what the most recent architecture is.
Sometimes sources would say different things about the same comp
onent (depending on
the date and source)

If we were to analyze the architecture of another software system, we would apply the following
lessons learned:



S
-
Q u e u e
-
L


P a g e
|
13



o

Try to find or determine the Reference Architecture immediately;
seeing how the
common database management system works made it much easier to piece together how
PostgreSQL
works.

o

Develop a further and more complete understanding of each architectural style before
deciding on one, as that would reduce speculation.

Glossary



SQL


Structured Queried Language

MVCC


Multi Version Concurrency Control used to allow sequential data reads and writes

IPC


Inter Process Communications.

CPU


Central Processing Unit

DBMS


Database Management System

JDBC



Lists JDBC featu
res, describes JDBC Architecture and reviews SQL commands and Relational
Database concepts.

Libqp



ibpq is a set of library functions that allow client programs to pass queries to the PostgreSQL
backend server and to receive the results of these querie
s

TCP/IP


Transmission control protocol / internet protocol used to exchange data between two hosts



























S
-
Q u e u e
-
L


P a g e
|
14








References:


1.

“About.”
http://www.postgresql.org/about/
.
PostgreSQL Global Development Group.
Web. 2010.

2.

“Advantages.”
http://www.postgresql.org/about/advantages
. PostgreSQL Global
Development Group. Web. 2010.

3.

“Executor.”
http://developer.postgresql.org/pgdocs/postgres/executor.html
. PostgreSQL
Global Development Group. Web. 2010.

4.

“Explicit Locking.”
http://www.postgresql.org/docs/9.0/interactive/explicit
-
locking.html
.
PostgreSQL Global Development Group. Web. 2010.

5.

“Frequently Asked Questions.”
http://www.postgresql.org/about/press/faq
. Post
greSQL
Global Development Group. Web. 2010.

6.

“How Connections Are Established"
http://www.postgresql.org/docs/9.0/interactive/connect
-
estab.html
.
PostgreSQL Global
Development G
roup. Web. 2010.

7.

“Index Cost Estimation Functions.”
http://www.postgresql.org/docs/9.0/interactive/index
-
cost
-
estimation.html
.
PostgreSQL Global Development Group. Web.
2010.

8.

Lane, Tom. “Transaction Processing in PostgreSQL.”
http://www.postgresql.org/files/developer/transactions.pdf
PostgreSQL Global
Development Group. Web. 30 Oct 2000.

9.

“Multi Version Concurrency Control.”
http://en.wikipedia.org/wiki/Multiversion_concurrency_control
.
PostgreSQL Global
Development Group. Web. 2010.


10.

“Parser Stage” .
http://www.postgresql.org/docs/9.0/interactive/parser
-
stage.html
.
PostgreSQL Global Development Group. Web. 2010.

11.

“Path of a query.”
http://www.postgresql.org/docs/9.0/interactive/query
-
path.html
.
PostgreSQL Global Development Group. Web. 2010.

12.


“Planner/Optimizer.”
http://developer.
postgresql.org/pgdocs/postgres/planner
-
optimizer.html
. PostgreSQL Global Development Group. Web. 2010.

13.

“Query Planning.”
http://www.postgresql.org/docs/9.0/interactive/r
untime
-
config
-
query.html
.
PostgreSQL Global Development Group. Web. 2010.


14.

“The Rule System.”
http://developer.postgresql.org/pgdocs/postgres/rules.html
.
PostgreSQL Global Developmen
t Group. Web. 2010.

15.

“The Statistics Collector.”
http://www.postgresql.org/docs/9.0/interactive/monitoring
-
stats.html
.
PostgreSQL Global Development Group. Web. 2010.