SELECT * FROM mytable WHERE p_id = 123456;
我运行一个解释，并看到以下输出：
Bitmap Heap Scan on mytable (cost=12.04..1632.35 rows=425 width=321)
Recheck Cond: (p_id = 543094)
-> Bitmap Index Scan on idx_mytable_p_id (cost=0.00..11.93 rows=425 width=0)
Index Cond: (p_id = 543094)
问题：
>为什么该查询执行堆扫描，然后进行位图索引扫描？
>为什么要检查425行？为什么操作的宽度321？
>什么是12.04..1632.35和0.00..11.93的成本告诉我？
对于记录，有773行，p_id值为123456.在mytable上有38列。
谢谢！
Why is that query doing a heap scan and then a bitmap index scan?
这不是，确切。 EXPLAIN输出显示执行节点的结构，其中“更高”级别(不缩进到远)从其下的节点中拉出行。因此，当位图堆栈扫描节点去拉其第一行时，位图索引扫描运行以确定要使用的行集合，并将第一行的信息传递到堆扫描。索引扫描传递索引以确定需要读取哪些行，并且堆扫描实际上读取它们。这个想法是，通过从头到尾读取堆，而不是按照索引顺序，它将执行较少的随机访问 – 来自给定页的所有匹配的行将在该页加载时被读取，并且足够的页可以被读取以便使用更便宜的顺序访问，而不是在磁盘上来回查找。
Why is it examining 425 rows?
不是。你运行EXPLAIN，它只显示估计和选择的计划，它不真正检查行。这使得与运行EXPLAIN ANALYZE相比，EXPLAIN的值相当有限，后者实际上运行查询并显示估计值和实际数字。
Why is the width of the operation 321?
显然这是mytable中的元组的大小(以字节为单位)。
What is the cost of 12.04..1632.35 and 0.00..11.93 telling me?
第一个数字是从该节点返回第一行的成本;第二个数字是返回该节点的所有行的开销。记住，这些是估计。单位是抽象成本单位。绝对数意味着什么;在规划中什么事项是哪个计划具有最低的成本。如果你使用光标，第一个数字很重要;否则通常是第二个数字。 (我认为它为一个LIMIT子句插值。)
通常需要调整可配置的成本因素(如random_page_cost和cpu_tuple_cost)，以准确地为您环境中的成本建模。没有这样的调整，比较成本很可能不匹配相应的运行时间，因此可能选择一个不太理想的计划。
