Postgres查询计划在查询方面有很大的差异，因为时间差范围增加了

Question

嘿，postgres的专家。我们一张桌子正面临着一种奇怪的行为。在增加查询时间戳范围的同时，也存在查询时间突然增加约5倍的临界点。

我们正在看的桌子：

                   Table "measurements.hourly_measurement_recordings"
        Column         |              Type              | Collation | Nullable | Default 
-----------------------+--------------------------------+-----------+----------+---------
 dimension_identifier  | integer                        |           | not null | 
 occasion_identifier   | integer                        |           | not null | 
 items_identifier      | bit(64)                        |           | not null | 
 beginning_of_timeslot | timestamp(0) without time zone |           | not null | 
 dumped_weight         | integer                        |           | not null | 
Indexes:
    "hourly_measurement_recordings_kind_identifier_type_identifier_p" UNIQUE, btree (occasion_identifier, dimension_identifier, items_identifier, beginning_of_timeslot)
    "hourly_measurement_recordings_kind_identifier_type_identifier_b" btree (occasion_identifier, dimension_identifier, beginning_of_timeslot)

第一个查询+计划：https://explain.depesz.com/s/LyzL

第二个查询+计划：https://explain.depesz.com/s/ZCvZ

这两个查询之间唯一的区别是增加了时间戳范围：

'2021-03-15 23:00:00Z', '2021-04-19 21:00:00Z'

vs

'2021-03-14 23:00:00Z', '2021-04-19 21:00:00Z'

如您所见，有一个从Parallel Bitmap Heap Scan到Parallel Seq Scan的转变，这增加了查询时间。

在这里，我对使用过的数据库做了一些说明：

运行在AWSdb.t3.media上的

• PostgreSQL v13.1
• ，带有2个vCPU、4GB内存、通用SSD (40 4GB)

我对数据库配置没有真正的经验，所以我不知道哪些参数可能对您有用-只要让我知道是否有更多的相关信息要分享。

谢谢你，尼克

Answer 1

可能会有一个临界点，其中seq扫描实际上比位图扫描更快。还有一个点，规划师认为seq扫描会变得更快。而这些几乎永远不会是完全一致的，因为规划师永远不会完美。所以，这并不令人惊讶。

值得注意的是，位图扫描已经在内存中找到了所需的每一个块。很难相信这是一个现实的情况。这可能是因为您重复运行了完全相同的查询。如果您查询一组不同的参数，从而使所有数据都已在内存中，该怎么办？

看起来您的运行方式或多或少是计划器的默认设置。但是对于SSD磁盘，random_page_cost的默认设置通常太高。将其改为1.1而不是4可能更合适。光是这一点就有可能将切入点移向适当的方向，尽管我不知道它是否会有足够的变化。

您的max_parallel_workers_per_gather设置似乎最后是2。但是对于t3中型实例，这可能应该是0或最多为1。(而且，如果您关心性能，首先不应该使用t3实例，因为它们的性能在设计上是不稳定的)。而且，您似乎在使用可扩展的IO类。但是一旦你用尽了你的IO学分，性能就会下降，这似乎已经发生在这里的seq扫描。