第一个查询希望找到 rows=74
，但实际上找到
rows=40250。
第二个查询期望找到
rows=897368并实际找到
rows=924699。
当然，处理23倍的行会花费更多的时间。因此，您的实际时间不足为奇。
的数据统计信息
updated_at > now()已过时。跑：
ANALYZE tickets;
并重复您的查询。而您是否认真地拥有数据
updated_at > now()呢？听起来不对。
但是，对于最近更改的数据而言，统计数据已过时也就不足为奇了。这是合乎逻辑的。如果查询依赖于当前统计信息，则必须先运行，
ANALYZE然后再运行查询。
还要进行测试（仅在您的会话中）：
SET enable_bitmapscan = off;
并重复第二次查询以查看没有位图索引扫描的时间。
为什么位图索引扫描更多行？
普通 索引扫描 按索引中的顺序从堆中获取行。这很简单，愚蠢而且没有开销。几行速度很快，但与行数不断增加的位图索引扫描相比，最终成本可能更高。
一个 位图索引扫描
从索引中收集行之前查表。如果同一数据页上有多个行，则可以节省重复访问的时间，并且可以使处理速度大大提高。行越多，机会越大，位图索引扫描将节省时间。
对于更多的行（大约占表的5％，很大程度上取决于实际数据），计划器将切换到表的 顺序扫描 ，并且根本不使用索引。
最佳的选择是Postgres 9.2引入的
仅索引扫描
。只有满足一些前提条件才有可能。如果所有相关列都包含在索引中，则索引类型支持该索引，并且可见性映射表指示数据页上的所有行对所有事务可见，而不必从堆（表）中获取该页，并且索引中的信息就足够了。
该决定取决于您的统计信息（Postgres希望找到多少行及其分布）以及成本设置，最重要的是
random_page_cost，
cpu_index_tuple_cost和
effective_cache_size。
