postgresql中的long UPDATE

我一直在一个包含2.5亿行和3个索引的表上运行UPDATE; 此UPDATE使用另一个包含3000万行的表.现在已经运行了大约36个小时.我想知道如果他们计划花费一百万天来完成它的事情,他们是否有办法找出完成的距离,我会杀了它; 但如果它只需要一两天,我会让它运行.这是命令查询:

UPDATE pagelinks SET pl_to = page_id
    FROM page
    WHERE 
        (pl_namespace, pl_title) = (page_namespace, page_title)
        AND
        page_is_redirect = 0
;

EXPLAIN不是这里的问题,我只提到大表有多个索引,以便在某种程度上证明更新它需要多长时间.但无论如何这里是EXPLAIN:

Merge Join  (cost=127710692.21..135714045.43 rows=452882848 width=57)
  Merge Cond: (("outer".page_namespace = "inner".pl_namespace) AND ("outer"."?column4?" = "inner"."?column5?"))
  ->  Sort  (cost=3193335.39..3219544.38 rows=10483593 width=41)
        Sort Key: page.page_namespace, (page.page_title)::text
        ->  Seq Scan on page  (cost=0.00..439678.01 rows=10483593 width=41)
              Filter: (page_is_redirect = 0::numeric)
  ->  Sort  (cost=124517356.82..125285665.74 rows=307323566 width=46)
        Sort Key: pagelinks.pl_namespace, (pagelinks.pl_title)::text"
        ->  Seq Scan on pagelinks  (cost=0.00..6169460.66 rows=307323566 width=46)

现在我还发送了一个并行查询命令,以便DROP一个pagelinks的索引; 当然它正在等待UPDATE完成(但我觉得无论如何都要尝试它!).因此,我无法从页面链接中选择任何内容,以免损坏数据(除非您认为杀死DROP INDEX postmaster进程是安全的？).

所以我想知道它们是否是一个可以跟踪死元组数量的表,因为知道UPDATE在完成任务时有多快或多远都会很好.

Thx(PostgreSQL并不像我想象的那么聪明;它需要启发式)