postgresql - Postgres 选择了一个错误的查询计划

Question

以下查询在 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 倍？

这个查询的另一个有趣的修改是......而不是 product.id = 24(就像在第一个查询中一样)，我使用 product.id =(选择 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 快速查找该产品的销售额。为什么在其他两种情况下不使用相同的查询计划？似乎忽略了统计数据。

表定义(稍微混淆/重命名):

                            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++ build 1600编译，64位

Config:除maintenance_work_mem外的默认配置，已增加到1GB。

操作系统:Microsoft Windows [版本 6.2.9200]

安装的 RAM 数量和大小:32GB

存储:单个 1TB SSD

Answer 1

在您的第一个查询中，计划器采取了捷径并使用了 sales.productid 上可用的 sales_productid_index，因为它被告知 sales.productid = product.id。与产品的连接在这个查询中实际做的唯一一件事是确保表中确实存在 id = 24 的行。

在第二个查询中，此快捷方式不可用。计划者可以选择转到产品，获取 id，然后使用 productid 上的索引扫描销售额，可能会获得类似的性能，但因为他不知道 name='new00000006' 会导致 id=24，所以他不能'不要猜测这条路径会导致多少行销售*。据他所知，他将对 3 亿行销售表的重要部分进行索引扫描。

*请注意，在第一个查询中，他猜测 productid=24 将得到 42393 行，而得到 34560 行。考虑到该表有 3 亿行，这非常接近。