The Postgres Next Generation Database Management System

Summary by: Steve Gribble and Armando Fox

One-line summary: 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).

Relevance

Flaws

• 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 paper.

Overview/Main Points

• 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 things up.
• POSTGRES Query Language
  • set-oriented query langauge (very SQL-like)
  • allows nested queries, transitive closure, time travel
  • "Fast Path": query language extended with function-name (param-list) 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) e.g.: 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.
• Implementation:
  • 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
• Performance:
  • questionable results reported - 2 times as fast as UCB ingres, but used fast path to implement all benchmark routines as C functions.