<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # 14.2\. 規劃器使用的統計信息 就像我們在上一節里展示的那樣,查詢規劃器需要估計一個查詢檢索的行數, 這樣才能選擇正確的查詢規劃。本節就系統用于這些估計的統計進行一些描述。 統計的一個部分就是每個表和索引中的記錄總數,以及每個表和索引占據的磁盤塊數。 這個信息保存在[`pg_class`](#calibre_link-578)表的 `reltuples`和`relpages`字段中。 我們可以用類似下面的查詢檢索這些信息: ``` SELECT relname, relkind, reltuples, relpages FROM pg_class WHERE relname LIKE 'tenk1%'; relname | relkind | reltuples | relpages ----------------------+---------+-----------+---------- tenk1 | r | 10000 | 358 tenk1_hundred | i | 10000 | 30 tenk1_thous_tenthous | i | 10000 | 30 tenk1_unique1 | i | 10000 | 30 tenk1_unique2 | i | 10000 | 30 (5 rows) ``` 我們在這里可以看到`tenk1`有10000行,它的索引也有這么多行,但是索引遠比表小得多(很正常)。 出于效率考慮,`reltuples`和`relpages` 不是實時更新的, 因此它們通常包含可能有些過時的數值。它們被`VACUUM`, `ANALYZE`和幾個DDL命令 (比如`CREATE INDEX`)更新。 `VACUUM`或者`ANALYZE`操作不掃描整個表(這是常見的情況), 將逐步基于掃描表的部分更新`reltuples`數,從而產生一個近似值。 在任何情況下,規劃器將把`pg_class`表里面的數值調整為和當前的物理表尺寸匹配, 以此獲取一個更接近的近似值。 大多數查詢只是檢索表中行的一部分,因為它們有限制待查行的`WHERE`子句。 因此規劃器需要對`WHERE`子句的_選擇性_進行評估, 選擇性也就是符合`WHERE`子句中每個條件的部分。 用于這個目的的信息存儲在[`pg_statistic`](#calibre_link-769)系統表中。 在`pg_statistic`中的記錄是由`ANALYZE`和`VACUUM ANALYZE`命令更新的, 并且總是近似值,即使剛剛更新完也不例外。 除了直接查看`pg_statistic`之外, 我們手工檢查統計的時候最好查看[`pg_stats`](#calibre_link-771)的視圖。 `pg_stats`被設計成更容易可讀的。 而且,`pg_stats`是所有人都可以讀取的,而`pg_statistic`只能由超級用戶讀取。 這樣就可以避免非特權用戶從統計信息中獲取一些和其他人的表內容相關的信息。`pg_stats`視圖是受約束的, 只顯示當前用戶可讀的表。比如,我們可以: ``` SELECT attname, inherited, n_distinct, array_to_string(most_common_vals, E'\n') as most_common_vals FROM pg_stats WHERE tablename = 'road'; attname | inherited | n_distinct | most_common_vals ---------+-----------+------------+------------------------------------ name | f | -0.363388 | I- 580 Ramp+ | | | I- 880 Ramp+ | | | Sp Railroad + | | | I- 580 + | | | I- 680 Ramp name | t | -0.284859 | I- 880 Ramp+ | | | I- 580 Ramp+ | | | I- 680 Ramp+ | | | I- 580 + | | | State Hwy 13 Ramp (2 rows) ``` 需要注意的是兩行顯示為同一列,1對應在`road`表(`inherited`=`t`)開頭的完整繼承層次結構。 而另一個只包含`road`表本身(`inherited`=`f`)。 在`pg_statistic`中通過`ANALYZE`存儲的信息的數量, 特別是給每個字段用的`most_common_vals`和`histogram_bounds`數組上的最大記錄數目 可以用`ALTER TABLE SET STATISTICS`命令設置, 或者是用運行時參數[default_statistics_target](#calibre_link-979)進行全局設置。 目前缺省的限制是 100個記錄。 提升該限制應該可以做出更準確的規劃器估計,特別是對那些有不規則數據分布的字段而言, 代價是在`pg_statistic`里使用了更多空間,并且需要略微多一些的時間計算估計數值。相比之下, 比較低的限制可能更適合那些數據分布比較簡單的字段。 有關規劃器使用統計信息的進一步詳情可參閱[Chapter 60](#calibre_link-1204)。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看