Concrete Architecture of Postgre SQL SQueueL Khurrum A

Concrete Architecture of Postgre. SQL S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen Mc. Donald, Wisam Zaghal CISC 322 - Fall 2010

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 Open. Grok online source code browser, Software Landscape Editor, online Postgre. SQL 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)

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

Conceptual Architecture Revisited - Layered Legend Expected Dependency Figure 2

Expected Subsystem Interdependencies Legend Expected Subsystem Interdependency Figure 3

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

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

Unexpected Subsystem Interdependencies Legend Expected Dependency Unexpected Dependency Figure 6

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

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

Utility Intra-Subsystem Dependencies Nodes/List Catalog Access General. Utils Unexpected Dependencies Utility component Figure 8

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

Reflexion Analysis – Investigate Gaps Propose Dependencies between Sub. Systems Conceptual subsystems Mapping source entities to subsystems Conceptual Architecture Extracted source dependencies Concrete Architecture Compare 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 New Expected Dependencies Subsystem Figure 11

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

Concurrency &Team Issues - Commit. Fests - 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