1). 预计的启动开销(在输出扫描开始之前消耗的时间，比如在一个排序节点里做排续的时间)。
2). 预计的总开销。
3). 预计的该规划节点输出的行数。
4). 预计的该规划节点的行平均宽度(单位：字节)。
这里开销(cost)的计算单位是磁盘页面的存取数量，如1.0将表示一次顺序的磁盘页面读取。其中上层节点的开销将包括其所有子节点的开销。这里的输出行数(rows)并不是规划节点处理/扫描的行数，通常会更少一些。一般而言，顶层的行预计数量会更接近于查询实际返回的行数。
现在我们执行下面基于系统表的查询：从查询结果中可以看出tenk1表占有358个磁盘页面和10000条记录，然而为了计算cost的值，我们仍然需要知道另外一个系统参数值。
补充：postgresql SQL COUNT(DISTNCT FIELD) 优化
背景统计某时段关键词的所有总数，也包含null （statistics 有400w+的数据，表大小为 600M），故
写出sql：
问题虽然是后台查询，但是太慢了，执行时间为为 38.6s，那怎么优化呢？
解决 方法1（治标）把这个定时执行，然后把sql结果缓存下，然后程序访问缓存结果，页面访问是快了些，但是本质上还没有解决sql执行慢的问题。
方法2（治本）优化sql，首先说说 count( distinct FIELD) 为啥这么慢，此处不再赘述了，请看这篇：https://www.jb51.net/article/65680.htm
优化内容：
修改为
比较执行过程比对，可以使用 explian anaylze sql语句 查看
以上为个人经验，希望能给大家一个参考，也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方，望不吝赐教。
