Chapter 2. PostgreSQL 內部極邑高

Table of Contents
2.1. 查詢經過的路徑
2.2. 連結是如何建立起來的
2.3. 分析器階段
2.3.1. 分析器
2.3.2. 轉換處理
2.4. PostgreSQL 規則系統
2.5. 規劃器/最佳化器
2.5.1. 生成可能的規劃
2.5.2. 規劃的資料結構
2.6. 執行器

作者: 本章最初是 Enhancement of the ANSI SQL Implementation of PostgreSQL的一部分, 它是 Stefan Simkovics 在維也納理工大學寫的碩士論文, 是由 O.Univ.Prof.Dr. Georg Gottlob和Univ.Ass. Mag. Katrin Seyr 指導的。

本章給出了 PostgreSQL 後端伺服器的內部情況的一個極邑高。 在閱讀完畢下面的章節後,你應該對查詢是如何處理的有一個概念了。 不過別指望我們在這裡有詳細的描述(我想,要對 PostgreSQL 裡面所有的資料結構和函數都做這樣的詳細描 述可能要超過 1000 頁的內容!)。 本章只是試圖幫助我們了解在後端裡面從收到查詢 到發出結果之間通常的控制和資料的流動。

2.1. 查詢經過的路徑

下面是一個簡短的描述一個查詢從開始到得到結果要經過的階段。

  1. 首先必須先建立起從應用程式到 PostgreSQL 伺服器的連結。應用程式向伺服器發送查詢然後接收從伺服器傳回的結果。

  2. 分析階段(parser stage) 檢查從應用程式(客戶端)發送過來的查詢, 核對語法並建立一個 查詢樹(query tree)

  3. 重寫系統(rewrite system) 接收分析階段來的查詢樹 且搜尋任意應用到查詢樹上的 規則(rules) (儲存在 系統表裡)並根據給出的 規則體(rule bodies) 進行轉換。 我們在 視圖(views) 的實現裡給出了重寫系統的一個應用。

    當一個查詢存取一個視圖時(也就是說,一個 虛擬表(virtual table) ),重寫系統改寫使用者的查詢, 使之成為一個存取帶有 視圖定義(view definition)基本表(base tables)的查詢。

  4. 規劃器/最佳化器(planner/optimizer) 接收(改寫的)查詢樹然後建立一個 查詢規劃(queryplan),這個查詢規劃是 執行器(executor)的輸入。

    它(規劃器/最佳化器)首先建立所有得出相同結果的可能的 路徑(paths) 。例如,如果待掃描的關系上有一個索引,那麼掃描的路徑就有兩個。 一個可能是簡單的順序尋找,而另一個可能就是使用索引的那個。 下一步是計算出每個索引執行的開銷,並且選擇和傳回開銷最少的那個。

  5. 執行器遞歸地走過 規劃樹(plan tree) 並且在這個過程中檢索規劃所代表的元組。 執行器在對關系進行掃描時使用 儲存系統(storage system) ,進行 排序(sorts)連線(joins), 計算 條件(qualifications) 並且最終交回生成的元組。

在隨後的章節裡,我們將對上面的每一個步驟進行更詳細的討論, 以便讓我們對 PostgreSQL的內部控制和資料結構有一個更準確的理解。