Concrete Architecture of PostgreSQL

Overview – Derivation Process – Conceptual Architecture Revisited – High Level Conceptual Dependencies – High Level Observed Dependencies (Concrete Architecture) Expose high level unexpected inter-dependencies – Utilities Intradependencies Interdependencies – Final Arcihtecture Style & Conceptual Modification – Use Case Revisted – Concurrency & Team Issues – Limitations – Lessons Learned – Conclusion

Derivation Process – Map components to our proposed conceptual architecture With aid of OpenGrok online source code browser, Software Landscape Editor, online PostgreSQL Manual, and source code decomposition – Analysis of dependencies for the now-grouped components, making note of missing & unexpected dependencies – Investigate gaps between conceptual dependencies & extracted concrete dependencies (Reflextion Analysis)

Propose Conceptual subsystems Dependencies between SubSystems Mapping source entities to subsystems Extracted source dependencies Conceptual Architecture Concrete Architecture Compare Gaps Investigate Reflexion Analysis - Conceptual Figure 1

Conceptual Architecture Revisited - Layered Legend Expected Dependency Figure 2

Expected Subsystem Interdependencies Expected Subsystem Interdependency Legend Figure 3

Propose Conceptual subsystems Dependencies between SubSystems Mapping source entities to subsystems Extracted source dependencies Conceptual Architecture Concrete Architecture Compare Gaps Investigate Reflexion Analysis - Concrete Figure 4

Unexpected Subsystem Interdependencies Expected Subsystem Interdependency Legend Unexpected Subsystem Interdependency Figure 5

Legend Expected Dependency Unexpected Dependency Figure 6 Unexpected Subsystem Interdependencies

pl test tutorial include tools snowball tsearch regex port foreign bin Miscellaneous

Query Processor Process Manager Client Communication Storage Manager Catalog GeneralUtils Nodes/List Access Utility Inter-Subsystem Dependencies Unexpected Dependencies All External Subsystems Depend on Expected Dependency Query Processor dependency Process Manager Client Comm. Dependency Storage Manager Utility Component Subsystems Figure 7

Catalog GeneralUtils Nodes/List Access Utility Intra-Subsystem Dependencies Unexpected Dependencies Utility component Figure 8

Backend Utilities Time zone Library Numeric.c Unexpected Dependencies Utility component General Utilities Intra-Subsystem Dependency Figure 9

Propose Conceptual subsystems Dependencies between SubSystems Mapping source entities to subsystems Extracted source dependencies Conceptual Architecture Concrete Architecture Compare Gaps Investigate Reflexion Analysis – Investigate Gaps Figure 10

Architecture Style Revisited Initially: Layered– Each layer only talks to the layer above or below Maybe: Minimally layered ? - too much coupling Now: Object Oriented – Function calls within and across various subsystems

High Level Conceptual Remodeling – Object Oriented Figure 11 New Expected Dependencies Subsystem

Client Library Interfac e Server Parser Stage Rewrite r Planner/ Optimizer Executo r Storage Manage r Storage Manage r Request to Log in Request to Log in Server and communi- cation channel created Logged in Query Sent Query Sent Query Sent Query Sent Executed Query Returned Executed Query Returned Executed Query Returned Catalog General Utilities General Utilities Nodes Server Requested Grammar rules and actions looked up Grammar rules and actions retrieved Copy node tree function called Node tree returned Tree manipulation function called Manipulated tree returned Tree comparison function called Tree manipulation function called Manipulated tree returned Parsed Tree Modified Tree Most Efficient Tree sent Access & Modify Tree Semantics lookup Semantics retrieved Comparison results returned Format type function called SQL format language returned Data Sent back Current execution state of the query Executed Query Returned Legend: Components Data Flow Function Call Duration of running component User Figure 12

Concurrency &Team Issues Team Issues -CommitFests -Review and commit patches if up to par -If not committed, feedback given and changes made Concurrency – MVCC snapmgr.c (Utils - time) – Snapshot of data proc.c (Storage – Lock Manager) – Frees lock associated with current transaction

Limitations – Software Landscape Editor, although powerful, was primitive – hard to use – Determining how to map source files in accordance with our conceptual architecture – Lack of documentation on important code fragments – Was difficult to conslidate utilities into one shared component, as utilities were scattered throughout the various levels of the system

Lessons Learned – Best way to understand High Level dependencies is to understand their origins on the lower levels – Importance of clear and efficient commenting – Group effort needed at every stage – Divide and Conquer proved to be much more difficult given the nature of the contain files and Lsedit – Working in pairs of 2 at a time per task proved to be most effective

Conclusions – All components were much more intertwined than originally suspected – Importance of reflexion analysis – We now believe the architecture to be Object-Orientated