4

次のクエリは 1.5 秒で終了します (テーブルには約 5 億行が含まれています)。

explain (analyze, buffers)
select sales.*
from sales
join product on (product.id = sales.productid)
join date on (date.id = sales.dateid)
where product.id = 24
order by date.timestamp
limit 200;

クエリ プラン: http://explain.depesz.com/s/8Ix

代わりに product.name を検索すると、ランタイムがまったく許容できない 200 秒に増加します。

explain (analyze, buffers)
select sales.*
from sales
join product on (product.id = sales.productid)
join date on (date.id = sales.dateid)
where product.name = 'new00000006'
order by date.timestamp
limit 200;

クエリプラン: http://explain.depesz.com/s/0RfQ

「new00000006」という名前の製品の ID は 24 であることに注意してください (上記の高速クエリと同じ ID)。証拠：

select name from product where id = 24;

    name
-------------
 new00000006

そのクエリが最初のクエリよりも 200 倍長くかかるのはなぜですか?

このクエリのもう 1 つの興味深い変更はこれです。product.id = 24 (最初のクエリのように) の代わりに、product.id = (select 24) を使用します。これも実行に 200 秒かかります (実際には、product.name を検索するときと同じ不適切なクエリ プランになります)。

explain (analyze, buffers)
select sales.*
from sales
join product on (product.id = sales.productid)
join date on (date.id = sales.dateid)
where product.id = (select 24)
order by date.timestamp
limit 200;

クエリプラン: http://explain.depesz.com/s/K3VO

統計表は、製品 ID 24 が「レア」であることを示しています。

select most_common_vals from pg_stats where tablename='sales' and attname='productid';

{19,2,7,39,40,14,33,18,8,37,16,48,6,23,49,29,46,41,20,53,47,26,38,1,32,42,56,57,10,15,27,50,30,45,51,58,17,36,4,25,44,43,5,22,11,35,52,9,21,12,24,31,28,54,34,3,55,13}

select most_common_freqs from pg_stats where tablename='sales' and attname='productid';

{0.020225,0.020119,0.0201133,0.0201087,0.0201,0.0200903,0.0200843,0.020069,0.0200557,0.0200477,0.0200427,0.0200303,0.0200197,0.020019,0.020012,0.0200107,0.0200067,0.020006,0.019995,0.0199947,0.0199917,0.019986,0.019986,0.0199777,0.0199747,0.0199713,0.0199693,0.019969,0.019967,0.019962,0.0199607,0.0199603,0.01996,0.0199567,0.0199567,0.0199533,0.019952,0.019951,0.0199467,0.019944,0.019944,0.01993,0.0199297,0.0199257,0.0199223,0.0199143,0.01989,0.0198887,0.019883,0.0198747,6.7e-005,6e-005,5.9e-005,5.6e-005,5.46667e-005,5.43333e-005,5.13333e-005,4.96667e-005}

製品 ID 24 の頻度は 6.7e-005 (「新製品」) ですが、古い製品の頻度は約 0.01 です。

統計によると、最初のクエリ プラン (1.5 秒で実行されるもの) は完全に理にかなっています。sales_productid_index を使用して、この製品の売上をすばやく見つけます。他の 2 つのケースで同じクエリ プランが使用されないのはなぜですか? 統計は無視されているようです。

テーブル定義 (少し難読化 / 名前変更):

                            Tabelle äpublic.salesô
  Spalte   |   Typ   | Attribute | Speicherung | Statistikziel | Beschreibung
-----------+---------+-----------+-------------+---------------+--------------
 id        | uuid    | not null  | plain       |               |
 dateid    | integer |           | plain       | 10000         |
 productid | integer |           | plain       | 10000         |
 a         | text    |           | extended    | 10000         |
 b         | integer |           | plain       | 10000         |
 x1        | boolean |           | plain       |               |
 x2        | boolean |           | plain       |               |
 x3        | boolean |           | plain       |               |
 x4        | boolean |           | plain       |               |
 x5        | boolean |           | plain       |               |
Indexe:
    "sales_pkey" PRIMARY KEY, btree (id)
    "sales_a_index" btree (a)
    "sales_b_index" btree (b)
    "sales_dateid_index" btree (dateid)
    "sales_productid_index" btree (productid)
Fremdschlnssel-Constraints:
    "sales_dateid_fkey" FOREIGN KEY (dateid) REFERENCES date(id)
    "sales_productid_fkey" FOREIGN KEY (productid) REFERENCES product(id)
Hat OIDs: nein

                                                 Tabelle äpublic.productô
 Spalte |   Typ   |                        Attribute                         | Speicherung | Statistikziel | Beschreibung
--------+---------+----------------------------------------------------------+-------------+---------------+--------------
 id     | integer | not null Vorgabewert nextval('product_id_seq'::regclass) | plain       |               |
 name   | text    |                                                          | extended    |               |
Indexe:
    "product_pkey" PRIMARY KEY, btree (id)
    "product_name_index" UNIQUE, btree (name)
Fremdschlnsselverweise von:
    TABLE "sales" CONSTRAINT "sales_productid_fkey" FOREIGN KEY (productid) REFERENCES product(id)
    TABLE "salesaggr" CONSTRAINT "salesaggr_productid_fkey" FOREIGN KEY (productid) REFERENCES product(id)
Hat OIDs: nein

バージョン: PostgreSQL 9.3.1、Visual C++ ビルド 1600 でコンパイル、64 ビット

構成: 1GB に増やされた maintenance_work_mem を除くデフォルト構成。

オペレーティング システム: Microsoft Windows [バージョン 6.2.9200]

インストールされている RAM の量とサイズ: 32GB

ストレージ: シングル 1TB SSD

4

1 に答える 1

2

最初のクエリでは、プランナーは近道を取り、sales.productid = product.id と伝えられているため、sales.productid で利用可能な sales_productid_index を使用します。このクエリで product との結合が実際に行う唯一のことは、id = 24 の行が実際にテーブルに存在することを保証することです。

2 番目のクエリでは、このショートカットは使用できません。プランナーは、product に移動し、id を取得してから、productid のインデックスを使用して売上をスキャンすることを選択でき、おそらく同様のパフォーマンスが得られますが、name='new00000006' が id=24 につながることを知らないため、できません。このパスが売上の何行になるかはわかりません*。彼が知っている限りでは、3 億行の sales テーブルのかなりの部分をインデックス スキャンすることになります。

*最初のクエリで、彼は productid=24 が 42393 行になり、34560 行になると推測していることに注意してください。テーブルに 3 億行あることを考えると、かなり近いです。

于 2013-12-02T17:29:24.660 に答える