私のPostgreSQLプランで行数が0になるのはなぜですか？

Question

私はネストされたループを使って2つのテーブル、TableAとTableBを等結合しているクエリを持っています。したがって、 "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つのテーブル定義...製品テーブル最初：

=> \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) 

Answer 1

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

http://www.postgresql.org/docs/current/static/using-explain.htmlを見てみると：一部のクエリ・プランで

を、サブプランノードが複数回実行することが可能です。たとえば、内側の索引走査は、上記の入れ子ループ計画で外側の行ごとに1回実行されます。そのような場合、ループ値はノードの実行の総数を報告し、実際の時間と行の値は実行ごとの平均値です。これは、コスト見積もりの​​表示方法に匹敵する数にするために行われます。ループ値を掛け合わせると、ノードで実際に費やされた合計時間が取得されます。

私は（私は平均化した後、最寄りのintにダウン推測している）、それを丸めるだかどうかはわかりませんが、それはproductsで最も行がstockに対応する行を持っていないということかもしれません。