我们遇到了一个奇怪的问题，Postgres，最初是在我们准备从10.21升级到11+时发现的。在较新版本的Postgres中，我们最初认为的是性能回归，实际上，一旦为我们的数据库生成了更准确的统计数据，性能回归就变成了性能回归。结果是，对于有问题的表，last_analyze和last_autoanalyze都是NULL。升级纠正了这一点，但使查询的某个子集变得慢得多。

背景

我们目前正在生产中运行PG 10.21。我们在这里交互的表events_test包括两个我们正在测试的列，account(varchar(40))和timestamp(timestamptz)。存在关于account、timestamp的指数和关于account和timestamp的综合指数。
我们的测试查询是

EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM events_test 
WHERE account = '1234' AND TIMESTAMP >= (NOW() AT TIME ZONE 'EST'  - interval '1 month');

我们正在对两个不同的account值进行测试--有些我们预计会返回大量数据(帐户1234返回数万行)，而另一些返回数量较少(帐户5678返回数十行)。
在我们当前的生产数据库上，这对于我们的目的来说运行得足够快，对于大响应(帐户1234)大约运行80-100ms，对于小响应(帐户5678)大约运行大约1ms。在这两种情况下，查询规划器都选择从对复合索引events_test_account_timestamp_idx进行索引扫描开始。

过期统计

对于返回大量行的帐户，查询规划器大大低估了要返回的行数-它估计大约500行，但实际上大约是60,000行。这是因为我们的生产数据库上的表统计数据已过期。
手动运行ANALYZE events_test;或升级到pg11、pg12或pg14(这似乎会导致在升级后不久运行此重新分析)更新表统计信息，并导致行估计值更接近真实值-对于返回更多数据的帐户，新估计值约为20,000行。

查询规划器

不幸的是，这种更准确的估计似乎会导致查询规划器运行效率低得多的查询。对于数据很少的帐户，行估计值不变，规划者继续使用综合指数。然而，对于返回数据量较大的帐户，规划器现在选择在events_test_timestamp_idx上进行索引扫描，然后在account字段上进行筛选，这会使查询的执行时间达到400-500ms。
预期返回少量行的查询将继续在所有版本的Postgres上使用复合索引。

我们尝试了什么

我们一直在寻找关于Postgres绕过综合指数的类似问题，但我们没有发现任何有用的东西。另外：

分析、重新索引、统计目标

我们已经尝试将default_statistics_target从100%更新到1000%(并且在10%和10000处也进行了短暂的尝试)，然后重新分析我们的表并重新建立索引，并且较慢的查询计划没有改变。

Postgres版本

这个问题最初是在我们针对较新版本的Postgres进行验证时发现的。我们在升级到PG11、PG12和PG14后进行了测试，在所有情况下都显示出性能较慢的查询规划。我们也可以通过重新分析来更新我们的统计数据，从而导致它在PG10上发生，所以这似乎不是Postgres更新中规划者行为的变化。

强制综合索引

我们已经通过以下测试命令验证了我们确实可以强制Postgres使用综合索引，方法是(临时)删除规划者现在首选的timestamp索引：

BEGIN;

DROP INDEX events_test_timestamp_idx;

EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM events_test 
WHERE account = '1234' AND TIMESTAMP >= (NOW() AT TIME ZONE 'EST'  - interval '1 month');

ROLLBACK;

这会导致postgres恢复到综合索引events_test_account_timestamp_idx，但是它现在选择对该索引执行位图索引扫描。这将继续以低于100ms的速度运行，在性能上可与之前对综合指数的直接指数扫描相媲美。

查询EXPLAIN s

以下是在生产环境中，在PG10上更高效地运行该查询时的样子：

Index Scan using events_test_account_timestamp_idx on events_test  (cost=0.11..1109.11 rows=579 width=206) (actual time=0.062..116.439 rows=71700 loops=1)
  Index Cond: (((account)::text = '1234'::text) AND ("timestamp" >= (timezone('EST'::text, now()) - '1 mon'::interval)))
  Buffers: shared hit=68619 read=1249
  I/O Timings: read=23.426
Planning time: 0.662 ms
Execution time: 119.339 ms

下面是在PG14上更新统计数据后的结果(但所有版本的输出都是相似的)：

Index Scan using events_test_timestamp_idx on events_test  (cost=0.11..31867.79 rows=18994 width=204) (actual time=0.164..311.960 rows=55583 loops=1)
  Index Cond: ("timestamp" >= ((now() AT TIME ZONE 'EST'::text) - '1 mon'::interval))
  Filter: ((account)::text = '1234'::text)
  Rows Removed by Filter: 462327
  Buffers: shared hit=492867
Planning:
  Buffers: shared hit=144 read=30
  I/O Timings: read=6.160
Planning Time: 7.021 ms
Execution Time: 314.676 ms

最后，如果我们通过临时删除时间戳索引来强制它使用综合索引，则在PG14上(但同样，在所有版本上都类似)：

Bitmap Heap Scan on events_test  (cost=187.05..35867.12 rows=18992 width=204) (actual time=11.373..38.937 rows=55582 loops=1)
  Recheck Cond: (((account)::text = '1234'::text) AND ("timestamp" >= ((now() AT TIME ZONE 'EST'::text) - '1 mon'::interval)))
  Heap Blocks: exact=13586
  Buffers: shared hit=13803
  ->  Bitmap Index Scan on events_test_account_timestamp_idx  (cost=0.00..186.10 rows=18992 width=0) (actual time=9.376..9.376 rows=55582 loops=1)
        Index Cond: (((account)::text = '1234'::text) AND ("timestamp" >= ((now() AT TIME ZONE 'EST'::text) - '1 mon'::interval)))
        Buffers: shared hit=217
Planning:
  Buffers: shared hit=5
Planning Time: 0.316 ms
Execution Time: 41.446 ms

• 编辑*：这里的核心问题似乎是，在准确的估计下，postgres预计单个指数的索引和筛选**将比使用综合指数(35867.12)快，而实际上在上面的情况下，综合指数快近10倍。这很有趣，因为上面最后两个EXPLAIN使用的是同一组统计数据来得出这些预测。