postgresqlデータベースの更新が遅い原因を解決します。

;約1400000本のデータが運行されていますが、一時間も経っていません。
以下は私の何時の解決策ですか？
私のudate文は臨時表から正式表に更新されました。
具体的なデータは秘密にしておく必要がありますので、図面を見ずに大体の考えと方法を話します。
1.語句に問題があるかどうかを確認する
同じテーブルとデータをコピーして手動で文を実行すると、1分もかからずに実行に成功しました。これで文の確認ができます。大丈夫です。
2.udataに影響を与える要因を検索する
私の第一反応はロックがあるかどうか、待ち時間やデッドロックになります。
クエリー錠

select w1.pid as     ,
w1.mode as      ,
w2.usename as     ,
w2.query as     ,
b1.pid as     ,
b1.mode      ,
b2.usename as     ,
b2.query as     ,
b2.application_name     ,
b2.client_addr   IP  ,
b2.query_start         
from pg_locks w1
join pg_stat_activity w2 on w1.pid=w2.pid
join pg_locks b1 on w1.transactionid=b1.transactionid and w1.pid!=b1.pid
join pg_stat_activity b2 on b1.pid=b2.pid
where not w1.granted;

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid='62560'

鍵があると調べたら、ロックを消して再起動します。5分後にまたロックがかかっています。何回か試してみましたが、ロックとは関係ないです。
3.クエリーパラメータ
まず見たのはshared_です。バグパラメータは、発見しても大丈夫です。

4.収縮表VACUUM
データを調べていると、自動収縮も10分間実行されています。まだ終わっていないので、テーブルが収縮している状況を調べます。
サーバーモニタに使用します。プロセスを確認できます。時間の消耗はロックに関連しています。

SELECT 

C.relname     ,
l.locktype        ,
l.pid   id,
l.MODE       ,
l.GRANTED           ,
l.fastpath,
psa.datname      ,
psa.usesysid   id,
psa.usename     ,
psa.application_name       ,
psa.client_addr    IP  ,
psa.client_port      TCP   ,
psa.backend_start       ,
psa.xact_start       ,
psa.query_start          ,
psa.state_change         ,
psa.wait_event_type       ,
psa.wait_event     ,
psa.STATE     ,

backend_xid          ,
backend_xmin        ,

psa.query     ,
now( ) - query_start     

FROM

pg_locks l
INNER JOIN pg_stat_activity psa ON ( psa.pid = l.pid )
LEFT OUTER JOIN pg_class C ON ( l.relation = C.oid )
-- where l.relation = 'tb_base_apparatus'::regclass

where relkind ='r'
ORDER BY query_start asc

自動整理のテーブルに到着したかどうかを調べます。

SELECT
 c.relname   ,
 (current_setting('autovacuum_analyze_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_analyze_scale_factor')::NUMERIC(12,4))*reltuples AS       ,
 (current_setting('autovacuum_vacuum_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_vacuum_scale_factor')::NUMERIC(12,4))*reltuples AS       ,
 reltuples::DECIMAL(19,0)     ,
 n_dead_tup::DECIMAL(19,0)     
FROM
 pg_class c 

LEFT JOIN pg_stat_all_tables d

 ON C.relname = d.relname
WHERE
 c.relname LIKE'tb%' AND reltuples > 0
 AND n_dead_tup > (current_setting('autovacuum_analyze_threshold')::NUMERIC(12,4))+(current_setting('autovacuum_analyze_scale_factor')::NUMERIC(12,4))*reltuples;

そして死の元祖が多すぎることを発見しました。
そして私は手動でこの表を収縮してから更新するのが速いです。

VACUUM FULL VERBOSE   ;
VACUUM FULL VERBOSE ANALYZE   ;

5.まとめ
このような場合はまずあなたのsql文を確認してください。その後、EXPLANロックがあるかどうか確認してください。データベースのパラメータを見てください。データベースの性能原因ではないですか？最後に収縮表が必要ですか？
ここで、postgresqlデータベースのアップデートが遅い原因についての記事を紹介します。postgresqlデータベースのアップデートの遅い内容については、以前の記事を検索したり、下記の関連記事を見たりしてください。これからもよろしくお願いします。