1 / 21

Concrete Architecture of PostgreSQL

Concrete Architecture of PostgreSQL. S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal. CISC 322 - Fall 2010. Overview. Derivation Process Conceptual Architecture Revisited High Level Conceptual Dependencies

charis
Download Presentation

Concrete Architecture of PostgreSQL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Concrete Architectureof PostgreSQL S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal CISC 322 - Fall 2010

  2. Overview • DerivationProcess • Conceptual Architecture Revisited • High LevelConceptualDependencies • High LevelObservedDependencies (Concrete Architecture) • Expose highlevelunexpected inter-dependencies • Utilities • Intradependencies • Interdependencies • Final Arcihtecture Style & Conceptual Modification • Use Case Revisted • Concurrency & Team Issues • Limitations • LessonsLearned • Conclusion

  3. DerivationProcess • Map components to our proposed conceptual architecture • Withaid of OpenGrok online source code browser, Software Landscape Editor, online PostgreSQLManual, and source code decomposition • Analysis of dependencies for the now-grouped components, making note of missing & unexpecteddependencies • Investigate gaps between conceptual dependencies & extractedconcretedependencies (ReflextionAnalysis)

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

  5. Conceptual Architecture Revisited - Layered Legend Expected Dependency Figure 2

  6. Expected Subsystem Interdependencies Legend Expected Subsystem Interdependency Figure 3

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

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

  9. Unexpected Subsystem Interdependencies Legend Expected Dependency Unexpected Dependency Figure 6

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

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

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

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

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

  15. Architecture Style Revisited Initially: Layered–Each layer onlytalks to the layer above or below Maybe: Minimallylayered ? - toomuchcoupling Now: Object Oriented–Function calls within and acrossvarioussubsystems

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

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

  18. 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

  19. Limitations • Software Landscape Editor, althoughpowerful, was primitive – hard to use • Determining how to map source files in accordance with our conceptualarchitecture • Lack of documentation on important code fragments • Wasdifficultto conslidate utilities into one shared component, as utilities werescatteredthroughout the variouslevels of the system

  20. LessonsLearned • Best way to understand High Leveldependenciesis to understandtheirorigins on the lowerlevels • Importance of clear and efficient commenting • Group effort neededatevery stage • Divide and Conquerproved to bemuch more difficultgiven the nature of the contain files and Lsedit • Working in pairs of 2 at a time per taskproved to bemost effective

  21. Conclusions • All components weremuch more intertwinedthanoriginallysuspected • Importance of reflexionanalysis • Wenowbelieve the architecture to be Object-Orientated

More Related