The POSTGRES Next - Generation Database Management System

1

• The POSTGRES Next - Generation Database
  Management System
• Michael Stonebraker
• Greg Kemnitz
• Presented by Nirav S. Sheth

2
Services offered by DBMS are of 3 kinds

• Traditional Data Management
• Simple data type
• Object Management
• Nontraditional data types, e.g. bitmaps, icons,
  text, polygons
• Knowledge Management
• Store and enforce a collection of rules that are
  a part of a semantics of an application

3
Example

• An application that stores and manipulates
  text and graphics to facilitate the layout of
  Newspaper copy
• Data customer information
• Object text, pictures and icons
• Rules control newspaper layout

4
The Postgres Data Model and query Language

• Three criteria guided the design of a new data
  model and query language for Postgres
• - Orientation toward database access from a
  query language
• - Orientation toward multilingual access
• - Small number of concepts

5
Orientation toward database access from a query
language

• Postgres users interact with database by using
  the set oriented query language-POSTQUEL
• Postgres gives each record a unique identifier
• Postgres allows a user to define
  functions(methods) to the DBMS

6
Orientation toward multilingual access

• Postgres could have tightly been coupled to the
  compiler and the run time environment of a
  specific language
• But most databases are accessed by programs
  written in several different languages
• Postgres is Multilingual
• POSTGRES is programming language neutral

7
Small number of concepts

• As few concepts as possible so that users have
  minimum complexity to contend with
• Four constructs
• Class
• Inheritance
• Type
• Function

8
The POSTGRES Data Model - Class

• Class a named collection of instances of objects
• Instances has the same collection of attributes
  and each attribute is of specific type
• Users can create a new class by specifying the
  class name, along with all attribute names and
  their types

9
The POSTGRES Data Model - Inheritance

• A class can inherit data elements from other
  classes
• Multiple inheritance only create objects
  without ambiguity

10
Three kinds of classes

• Real instances are stored in the database
• Derived(view or virtual class) instances are not
  physically stored but are materialized only when
  necessary
• Version store differential relative to its base
  class
• Initially has all instances of the base class
• Updates to the version do not affect the base
  class
• Updates to the base class are reflected in the
  version

11
The POSTGRES Data Model - Types

• Postgres contains an abstract data type(ADT)
  facility whereby any user can construct arbitrary
  new base types such as bits, bitstrings, encoded
  character strings, bitmaps, compressed integers,
  etc.
• Array of base types supported by Postgres
• Composite types allow to construct complex
  objects i.e. attributes which contain other
  instances as or all of their value

12
Composite Types

• Two kinds are
• - Zero or more instances of any class is
  automatically a composite type
• - Set, whose value is a collection of instances
  from all classes

13
POSTGRES notion of Functions

• Three different kinds of Functions are known to
  Postgres
• - C functions
• - Operators
• - POSTQUEL functions

14
C Functions

• These are Arbitrary C procedures
• Arguments of C functions are base or composite
  types
• C functions can be defined to POSTGRES while the
  system is running and are dynamically loaded when
  required during query execution
• Inherited down the class hierarchy
• Can not be optimized by the POSTGRES

15
Operators

• Operators utilize indexes
• Functions with one or two operands
• It is imperative that a user be able to construct
  new access methods to provide efficient access to
  instances of non traditional base types.
  Operators allow this

16
POSTQUEL

• Set-oriented query language that resembles a
  superset of a relational query language
• Support nested queries
• Transitive closure
• Support for inheritance
• Support for time travel

17
Reasons for FAST PATH

• There are a variety of decision support
  applications in which the end user is given a
  specialized query language
• It is necessary for the run time system to assign
  a unique identifier to every persistent object it
  constructs

18
The Rules System

• Requirements
• Referential integrity
• View management
• Triggers
• Integrity constraints
• Protection
• Version control

19
Implementation of Rules

• Two implementations for Postgres rules
• Through record level processing
• Query rewrite module

20
Record Level Processing

• Rules system is called when individual records
  are accessed, deleted, inserted or modified
• Place a marker on the record this marker
  contains the identifier of the corresponding rule
  and the types of events to which it is sensitive
• Efficient if there are large number of rules and
  each covers only a few instances

21
Query rewrite module

• Perform poorly if there are large number of small
  scope rules
• Performs admirably if there are small number of
  large scope rules

22
Rule Activation Policies

• Immediate-same transaction
• Immediate-different transaction
• Deferred-same transaction
• Deferred-different transaction
• Postgres only implements the first option

23
Storage System

• Postgres implements the idea of no-overwrite
  storage manager
• Old record remains in the database whenever an
  update occurs and servers the purpose normally
  performed by a write ahead log
• Postgres log is two bits per transaction
  indicating whether each transaction committed,
  aborted, or is in progress

24
Storage System contd.

• Two features can be exploited in a no-overwrite
  system
• Instantaneous crash recovery
• Time travel
• Stable main memory required
• Trade-off is that a POSTGRES database at any
  given time will have committed instances
  intermixed with instances that were written by
  aborted transactions

25
Storage System contd.

• To support time travel, Postgres maintains two
  different physical collections of records, one
  for current data and one for historical data,
  each with its own indexes
• A demon know as vacuum cleaner runs in the
  background which moves records that are no longer
  valid from the current database to historical
  database

26
The POSTGRES Implementation

• Aspects of the implementation that deserve
  special mention are the process structure
  extendibility dynamic loading and the rule
  wake-up
• Process Structure Postgres runs as one process
  for each active user but all users share the
  Postgres code, buffer pool and lock table but
  they have private data segments

27
The POSTGRES Implementation-contd.

• Extendibility has been accomplished by making
  the parser, optimizer and execution engine
  entirely table driven.
• Data types, operators and functions can be added
  and subtracted dynamically i.e. when the system
  is running
• Maintains a cache of currently loaded functions
  and dynamically moves functions into the cache
  and then ages them out.

28
POSTGRES Performance

• Better than UCB-INGRES

29
POSTGRES Performance
30
Conclusion

• POSTGRES allows an application designer to trade
  off performance for data independence
• Imports only specific user functions into its
  address space