6

ネストされたループを使用して、TableAとTableBの2つのテーブルを等結合するクエリがあります。「equi」-結合制約のため、結果で返されるすべての行は、これら2つのテーブルのそれぞれからの少なくとも1つの行に対応します。ただし、計画（EXPLAIN ANALYZE）によると、最終結果で行が返されても、TableBからの実際の行数は0です。ここで実際の行数をゼロにするにはどうすればよいですか？

実行計画は次のとおりです。

=> explain analyze select p.id, p.title, s.count from products p, stock s where p.id = s.p_id and s.w_id = 6 and p.type = 9 and s.count > 0 order by p.title;
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=42.42..42.42 rows=2 width=36) (actual time=0.198..0.199 rows=1 loops=1)
   Sort Key: p.title
   Sort Method: quicksort  Memory: 25kB
   ->  Nested Loop  (cost=0.00..42.41 rows=2 width=36) (actual time=0.170..0.181 rows=1 loops=1)
         ->  Seq Scan on products p  (cost=0.00..9.25 rows=4 width=32) (actual time=0.068..0.106 rows=4 loops=1)
               Filter: (type = 9)
         ->  Index Scan using stock_pk on stock s  (cost=0.00..8.28 rows=1 width=8) (actual time=0.015..0.015 rows=0 loops=4)
               Index Cond: ((w_id = 6) AND (p_id = p.id))
               Filter: (count > 0)
 Total runtime: 0.290 ms

そして、2つのテーブル定義...最初にproductsテーブル：

=> \d products
           Table "public.products"
 Column |          Type          | Modifiers 
--------+------------------------+-----------
 id     | integer                | not null
 title  | character varying(100) | 
 type   | integer                | 
 price  | double precision       | 
 filler | character(500)         | 
Indexes:
    "products_pkey" PRIMARY KEY, btree (id)
    "products_type_idx" btree (type)
Referenced by:
    TABLE "orderline" CONSTRAINT "orderline_p_id_fkey" FOREIGN KEY (p_id) REFERENCES products(id)
    TABLE "stock" CONSTRAINT "stock_p_id_fkey" FOREIGN KEY (p_id) REFERENCES products(id)

在庫表：

=> \d stock
     Table "public.stock"
 Column |  Type   | Modifiers 
--------+---------+-----------
 w_id   | integer | not null
 p_id   | integer | not null
 count  | integer | 
Indexes:
    "stock_pk" PRIMARY KEY, btree (w_id, p_id)
    "stock_p_id_idx" btree (p_id)
Foreign-key constraints:
    "stock_p_id_fkey" FOREIGN KEY (p_id) REFERENCES products(id)
    "stock_w_id_fkey" FOREIGN KEY (w_id) REFERENCES warehouses(id)
4

1 に答える 1

5

内部インデックススキャンの実際の行は、その呼び出しごとに返される行の平均数です。

http://www.postgresql.org/docs/current/static/using-explain.htmlを見てください：

一部のクエリプランでは、サブプランノードが複数回実行される可能性があります。たとえば、内側のインデックススキャンは、上記のネストされたループプランの外側の行ごとに1回実行されます。このような場合、ループ値はノードの実行の総数を報告し、表示される実際の時間と行の値は実行ごとの平均です。これは、コスト見積もりが表示される方法と数値を比較できるようにするために行われます。ループ値を掛けて、ノードで実際に費やされた合計時間を取得します。

どのように丸められるかはわかりませんが（平均化した後、最も近いintに推測しています）、のほとんどの行にproducts対応する行がない可能性がありますstock。

于 2012-04-19T08:23:37.713 に答える