建站
咨詢
售后
建站咨詢
新聞中心
一棵完成 transform 和 rewrite 操作的查詢樹是否是一棵***的查詢樹？如果不是，那么又該如何對該查詢樹進行優(yōu)化？而優(yōu)化所使用的策略正是本文要討論的重點內容，而且優(yōu)化部分也是整個查詢引擎的難點。
創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網站設計、網站建設、企業(yè)官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯(lián)網時代的芙蓉網站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！
子鏈接（SubLink）如何優(yōu)化？子查詢（SubQuery）又如何處理？對表達式（Expression）如何進行優(yōu)化？如何尋找***的查詢計劃（Cheapest Plan）？哪些因素會影響 JOIN 策略（Join Strategies）的選擇，而這些策略又是什么？查詢代價（Cost）又是如何估算的？何時需對查詢計劃進行物化（Plan Materialization）處理等一系列的問題。
在查詢計劃的優(yōu)化過程中，對不同的語句類型有著不同的處理策略：
（1）對工具類語句（例如，DML、DDL 語句），不進行更進一步的優(yōu)化處理。
（2）當語句為非工具語句時，PostgreSQL 使用 pg_plan_queries 對語句進行優(yōu)化。
與前面一樣，PostreSQL 也提供定制化優(yōu)化引擎接口，我們可以使用自定義優(yōu)化器 planner_hook，或者使用標準化優(yōu)化器 standard_planner。
Pg_plan_queries 的函數(shù)原型如下所示。
邏輯優(yōu)化——整體架構介紹
在未使用第三方提供的優(yōu)化器時，PostgreSQL 將 planner 函數(shù)作為優(yōu)化的入口函數(shù)，并由函數(shù) subquery_planner 來完成具體的優(yōu)化操作。從下圖中的 Call Stack 我們可以看出 planner 與 subquery_planner 之間的調用關系。
函數(shù)以查詢樹作為輸入?yún)?shù)，并以優(yōu)化后語句作為返回值。
在 standard_planner 中，首先處理 “DECLARE CURSOR stmt” 形式的語句，即游標語句，并設置 tuple_fraction 值。那么 tuple_fraction 又是什么呢？
tuple_fraction 描述我們期望獲取的元組的比例，0 代表我們需要獲取所有的元組；當 tuple_faction?(0,1) 時，表明我們需要從滿足條件的元組中取出 tuple_faction 這么多比例的元組；當 tuple_faction? [1,+￥ ) 時，表明我們將按照所指定的元組數(shù)進行檢索，例如，LIMIT 語句中所指定的元組數(shù)。
完成對 tuple_faction 的設置后，進入后續(xù)優(yōu)化流程，subquery_planner 的函數(shù)原型如下所示。
這里也許你也許會迷惑，為什么是 subquery_planner 呢？從名字上看該函數(shù)像是用來處理子查詢，那么為什么用來作為整個查詢語句優(yōu)化的入口呢（Primary Entry Point）？
子查詢語句作為查詢語句的一部分，很大程度上與父查詢具有相似的結構，同時兩者在處理方式和方法上也存在著一定的相似性：子查詢的處理流程可以在對其父查詢的過程中使用。例如，本例中的子查詢語句 SELECT sno FROM student WHERE student.classno = sub.classno，其處理方式與整個查詢語句一樣。因此，使用 subquery_planner 作為我們查詢優(yōu)化的入口，雖然從函數(shù)名上來看其似乎是用于子查詢語句的處理。
由 gram.y 中給出的 SelectStmt 的定義可以看出，其中包括了諸如 WINDOWS、HAVING、ORDER BY、GROUP BY 等子句。那du么 subquery_planner 函數(shù)似乎也應該有相應于這些語句的優(yōu)化處理。就這點而言，subquery_planner 與原始語法樹到查詢樹的轉換所采取的處理方式相似。根據(jù)上述分析，我們可給出如下所示的 subquery_planner 的函數(shù)原型。
按照上述給出的原型，只要完成假定的 process_xxx 函數(shù)，就可以實現(xiàn)對查詢語法樹的優(yōu)化工作。是不是覺得很簡單？當然不是，原理很簡單，但是理論與實際還有一定的距離。
例如，如何處理查詢中大量出現(xiàn)的子鏈接？如何對 d 算子執(zhí)行 “下推”？如何選擇索引？如何選擇 JOIN 策略？這些都需要我們仔細處理。
PostgreSQL 給出的 subquery_planner 如下所示。
由 PostgreSQL 給出的實現(xiàn)可以看出，核心處理思想與我們討論的相一致：依據(jù)類型對查詢語句進行分類處理。
這里需要注意的一點就是查詢計劃的生成部分，PostgreSQL 將查詢計劃的生成也歸入 subquery_planner 中，但為了方便問題的討論，我們并未將查詢計劃的生成部分在 subquery_planner 中給出。我們將查詢優(yōu)化的主要步驟總結如下：
處理 CTE 表達式，ss_process_ctes； 上提子鏈接，pull_up_sublinks； FROM 子句中的內聯(lián)函數(shù)，集合操作，RETURN 及函數(shù)處理，inline_set_returning_ functions； 上提子查詢，pull_up_subqueries； UNION ALL 語句處理，flatten_simple_union_all； 處理 FOR UPDATE（row lock）情況，preprocess_rowmarks； 繼承表的處理，expand_inherited_tables； 處理目標列（target list），preprocess_expression； 處理 withCheckOptions，preprocess_expression； 處理 RETURN 表達式，preprocess_expression； 處理條件語句 - qual，preprocess_qual_conditions； 處理 HAVING 子句，preprocess_qual_conditions； 處理 WINDOW 子句，preprocess_qual_conditions； 處理 LIMIT OFF 子句，preprocess_qual_conditions； WHERE 和 HAVING 子句中的條件合并，如果存在能合并的 HAVING 子句則將其合并到 WHERE 條件中，否則保留在 HAVING 子句中； 消除外連接（Outer Join）中的冗余部分，reduce_outer_joins； 生成查詢計劃，grouping_planner。
網頁題目：PostgreSQL邏輯優(yōu)化—這樣搭建整體架構
當前鏈接：http://www.5511xx.com/article/cdssicg.html
