Back to index
The Postgres Next Generation Database Management System
Michael Stonebraker and Greg Kemnitz.
Summary by: Steve Gribble and Armando Fox
A "feature-list" of the next-generation Postgres DBMS; postgres
(which deals with data management) was expanded to handle object management
and knowledge management (rulesets).
Trendy ORDBMS system - cool features.
- I just don't buy the performance numbers.
- How much of the extensibility/language features/fast path stuff
will users want to and be able to use? On the other hand, if it
doesn't cost anything (in performance/reliability) to provide the
features, why not do it?
- This article read more like a feature list than a technical
- POSTGRES Data Model
- emphasizes access from POSTQUEL database language, but
Postgres is "language neutral", and has
fast path facilities which allow you to make
direct calls to Postgres internals.
- relations in postgres are called classes; tuples are
called instances. Instances are collections of
attributes, each of which is of a specific type.
Classes have inheritance; there are real and derived
classes, and multiple inheritance.
- set of base types (strings, characters, integers,
dates, ...), and abstract data type (ADT) facility that
allows users to construct new base types.
- Composite types: build complex objects (objects
containing other objects, sets, etc.)
- Classes can have methods (function whose argument is a
class name). Can also introduce new operators (one or
more arguments). Authors can provide hints to query
optimizer regarting their operators to help speed
- POSTGRES Query Language
- set-oriented query langauge (very SQL-like)
- allows nested queries, transitive closure, time travel
- "Fast Path": query language extended with
notation, where function-name is an internal POSTGRES
function. E.g., author can construct parse tree and
bypass SQL parser.
- POSTGRES Rules System
- general purpose rules system that provides view
management, triggers, integrity constraints,
referential integrity, protection, and version control.
- rule syntax:
ON event (TO) object WHERE POSTQUEL-qualification
THEN DO [instead] POSTQUEL-command(s)
on new EMP.salary where EMP.name = "Fred"
then do replace E (salary = new.salary) from E in EMP
where E.name = "Joe"
- foward chaining: one rule triggers another. backward
chaining: is fred's salary is not explicitly stored,
more rules would be awakened to see whether or not this
rule should be triggered.
- rules mark attributes of instances that affect the rule
- if executor touches a marked attribute, it calls rule
system before proceeding. Marker escalation - if
sufficient number of markers in class, place enclosing
marker on entire class instead.
- clever query rewriting to help avoid have rules
triggered on every attribute touch by executor.
- rule semantics: immediate vs. deferred rules. Rules
running as part of or separate from transactions.
- can compile rules into postgres to extend
implementation of postgres (e.g. can implement views
and versions using rules)
- POSTGRES storage system: see The Design of
the Postgres Storage System paper.
- one process per active user - done for fast prototyping
- ducked complexity issue of single-server process
- parser, optimizer, execution engine are all
table-driven, "hence postgres is extendible"
- datatypes, operators, and functions can be
added/subtracted dynamically while postgres is running
- questionable results reported - 2 times as fast as UCB
ingres, but used fast path to implement all benchmark
routines as C functions.
Back to index