Postgresql Postgres批量更新以不合理的低阈值切换到顺序扫描

我有一张有很多行的桌子，大约260k。数据结构如下：

CELLS
id | values (float[])
-------------------
1  | [2.6, 2,7,...]
2  | [4.5, 1.3,...]

Update on cells  (cost=15499.17..11140840.53 rows=4692619 width=230)
  ->  Nested Loop  (cost=15499.17..11140840.53 rows=4692619 width=230)
        ->  Values Scan on "*VALUES*"  (cost=0.00..0.04 rows=3 width=96)
        ->  Bitmap Heap Scan on cells  (cost=15499.17..3694060.92 rows=1564206 width=170)
              Recheck Cond: (id = "*VALUES*".column1)
              ->  Bitmap Index Scan on cells_primary_idx  (cost=0.00..15108.12 rows=1564206 width=0)
                    Index Cond: (id = "*VALUES*".column1)

我正在尝试使用postgres中的

FROM

语法进行批量更新

UPDATE cells
SET values[174]=update_values.val
 FROM (
        VALUES
        (1, 1.0), (2, 1.0), (3, 1.0)
) AS update_values (id, val)
WHERE cell.id = update_values.id

当更新查询中的值小于等于3时，查询计划如下所示：

CELLS
id | values (float[])
-------------------
1  | [2.6, 2,7,...]
2  | [4.5, 1.3,...]

Update on cells  (cost=15499.17..11140840.53 rows=4692619 width=230)
  ->  Nested Loop  (cost=15499.17..11140840.53 rows=4692619 width=230)
        ->  Values Scan on "*VALUES*"  (cost=0.00..0.04 rows=3 width=96)
        ->  Bitmap Heap Scan on cells  (cost=15499.17..3694060.92 rows=1564206 width=170)
              Recheck Cond: (id = "*VALUES*".column1)
              ->  Bitmap Index Scan on cells_primary_idx  (cost=0.00..15108.12 rows=1564206 width=0)
                    Index Cond: (id = "*VALUES*".column1)

您可以看到，它在cells表上使用索引扫描，而且性能非常好，所需时间不到一秒钟。 但是，只要我在VALUES子句中添加第四个元素，查询计划就会切换到顺序扫描，我无法完成查询

Update on cells  (cost=0.10..11828380.08 rows=6256826 width=230)
  ->  Hash Join  (cost=0.10..11828380.08 rows=6256826 width=230)
        Hash Cond: (cells.id = "*VALUES*".column1)
        ->  Seq Scan on cells  (cost=0.00..10577014.84 rows=312841284 width=170)
        ->  Hash  (cost=0.05..0.05 rows=4 width=96)
              ->  Values Scan on "*VALUES*"  (cost=0.00..0.05 rows=4 width=96)

从3->4更新的变化占总行数的百分比是如此微不足道，我不明白为什么查询计划器在这方面做得如此之远

---

最终目标是将更新的当前状态（260k个更新状态）分解为大小合理的批量更新查询，但是，对于超过3行的任何内容，使用FROM语法的批处理更新都不会完成。

您是否试图为某些ID将第174个数组元素的值设置为1.0？@AvinKavish实际上，查询需要为所有ID运行，它会为表中的每一行更新数组中的一个元素。最好使用顺序访问，不是吗？对于这个特殊问题，如果不改变查询计划，可能需要对表进行真空分析，甚至重新编制索引。总行数是多少？@AvinKavish抱歉，我应该澄清一下，我的目标是将查询从一组庞大的260k UPDATE语句集中到一起，分解成大小更合理的块。我希望获得值语法性能，以便一次更新约1000行。我将编辑我的问题以澄清。计划者显然认为，有了4个值，它将更新6256826行（这似乎几乎是所有行）。该表的统计数据是否最新（例如，

vacuum analysis cells

fix？）