PostgreSQLがバキュームテーブルの情報を収集する必要があることを発見する方法
プリアンブル
通常、PostgreSQLでは、UPDATEとDELETEを頻繁に行う必要があるため、テーブルが断片化されています。
PostgreSQLでは、VACUUMを使用すると、VACUUMを実行する必要があるテーブルに対して削除された領域を未使用としてマークし、後で領域を再利用できるようにするだけで、占有した領域をOSにすぐに返さないので、領域を解放してOSにすぐに返すにはVACUUM FULLが必要です。
スクリプトの実装
レコードコレクション・テーブル作成
CREATE TABLE IF NOT EXISTS tab_vacuum_record
(sqltext text);
必要なVACUUMテーブルの機能を収集する
CREATE OR REPLACE FUNCTION f_vacuum_tables()
RETURNS void AS
$FUNCTION$
DECLARE
v_tablename text;
v_dead_cond bigint;
v_sql text;
cur_tablename REFCURSOR;
v_vacuum_record text;
BEGIN
v_vacuum_record := 'tab_vacuum_record';
OPEN cur_tablename FOR SELECT tablename FROM pg_tables WHERE tablename ! ~ '^pg|^sql';
LOOP
FETCH cur_tablename INTO v_tablename;
SELECT n_dead_tup INTO v_dead_cond FROM pg_stat_user_tables WHERE relname = v_tablename;
IF v_dead_cond > 0 THEN
v_sql := 'INSERT INTO ' || v_vacuum_record || ' VALUES(' || chr(39) || 'VACUUM FULL ' || v_tablename ||';'|| chr(39) ||')';
EXECUTE v_sql;
END IF;
EXIT WHEN NOT FOUND;
END LOOP;
CLOSE cur_tablename;
END;
$FUNCTION$
LANGUAGE PLPGSQL;
SHELLスクリプト
#! /bin#Get environment variables
CURRDIR=$(cd "$(dirname $0)";pwd)
TOPDIR=$(cd $CURRDIR/... ;pwd)
CONFIG=$TOPDIR/conf/host.ini
CT_FILE=${TOPDIR}/sql/CREATE_VACCUM_TABLE_RECORD.sql
CT_FUNCTION=${TOPDIR}/sql/CHECK_NEEDS_VACUUM_TABLE_FUNCTION.sql
source $CONFIG
CONNINFO="psql -U $USER -d $DBNAME -h $HOSTADDR -p $PORT"
function check_status()
{
echo "Checking if the database server status is OK ! "
stat=`$CONNINFO -Aqt -c 'SELECT 1'`
if [ "${stat}" == "1" ];then
echo "Server connection OK"
else
echo "Server connection abnormal, exit"
exit -1;
fi
}
function create_table()
{
echo "Creating a table to collect the required vacuum"
$CONNINFO -f $CT_FILE
}
function create_function()
{
echo "Create function that collects tables that require vacuum"
$CONNINFO -f $CT_FUNCTION
}
check_status
create_table
create_function
実行方法
postgres=# SELECT * FROM f_vacuum_tables();
f_vacuum_tables
-----------------
(1 row)
--create test tables
postgres=# CREATE TABLE tab_test(id int);
--insert data
postgres=# INSERT INTO tab_test SELECT id FROM generate_series(1,100000) as id;
INSERT 0 100000
--delete data
postgres=# DELETE FROM tab_Test WHERE id <= 10000;
DELETE 10002
postgres=# SELECT * FROM tab_vacuum_record ;
sqltext
-----------------------
VACUUM FULL tab_test;
(1 row)
また、このスクリプトは、以下のように自分のニーズに合わせて変更することができます。 ギズブ
追記 PostgreSQLにおけるVacuumの簡単な説明
VACUUM ドキュメント
ルーティングのクリーンアップ
PostgreSQLは定期的なメンテナンスとクリーンアップを必要とします。これは通常デーモンによって自動的に行われますが、我々はパラメータを調整するだけでよく、また、定期的にリサイクルをクリーンアップするスクリプトを実行することも可能です。
バキュームの基礎知識
PGは以下の理由で、各テーブルに対してVacuumコマンドを実行する必要がありました。
1. 行の更新や削除によって占有されたディスクスペースを取り戻し再利用するため
2. PGクエリプランで使用するデータ分析を更新するため
3. 読み取り専用インデックススキャンの可視化セットを更新するには
4、トランザクションIDやトランザクションIDの混在による履歴データの消失を回避するため
これらの理由から、VACUUM操作を頻繁に行う場合は、そのための準備を行う。
標準的なVACUUM
リサイクルの場合、本番環境は、データベースライブラリ(SELECT、INSERT、UPDATE、DELETE)の通常の使用に影響を与えません、並列使用、クリーンアップは、テーブル構造(ALTER TABLE)の変更を許可しないこのプログラムを使用することをお勧めします。
VACUUM FULL
a. 多くのスペースを再生できるが、標準的な再生実行より遅い。
b. 実行時にテーブルロックが必要
VACUUMを実行すると読み書きのパフォーマンスが低下するため、いくつかのパラメータを調整して影響を軽減する必要がある
temp_file_limit = -1 #default -1 means no limit on the maximum temporary files per process, in kilobytes
#max_files_per_process = 1000 #Maximum number of files allowed to be opened simultaneously per child process
VACUUMおよびANYLYZEの実行中、システムは各種I/O操作の消費量を推定するための内部カウンタを保持します。この値が vacuum_cost_limit の値に達すると、プロセスは vacuum_cost_delay で指定された時間だけスリープし、カウンタ値をリセットして VACUM または ANYLYZE の実行を継続します。 操作
vacuum_cost_limit = 200
vacuum_cost_delay = 0 # in microseconds, default is 0 not on
このパラメータvacuum_cost_delayは、主に並行処理中のI/Oの影響を軽減するために使用され、10を推奨します。
vacuum_cost_page_hit = 1 # means look up the shared hash table from the cache pool and scan the contents of the 'page'
Estimated value of #
vacuum_cost_page_miss = 10 # 0-10000 credits
vacuum_cost_page_dirty = 20
注意事項
VACUUMは、テーブル内に大量のデータがあり、削除や更新の操作が同時に行われる場合には、最適なソリューションではありません。
このような場合は、VACUU FULLを使用し、ALTER TABLEを実行すると、テーブル全体が再度コピーされるようにする必要があります。
を実行し、インデックスを再構築し、実行ロックを行い、新しいデータがコピーされるまで一時的に元のテーブルと同じサイズのディスクスペースを占有します。
アップグレード実行計画
実行計画では、ANALYZEコマンドを単独で、またはVACUUMで呼び出すことにより、統計情報を収集します。
式インデックスを作成することで、クエリの実行計画を改善することができる
default_statistics_target = 100 #Improve the query's analysis plan
上記は私の個人的な経験ですが、参考にしていただき、BinaryDevelopをより支持していただければと思います。もし、間違いや不完全な考察があれば、遠慮なくアドバイスしてください。
関連
-
PostgreSQLのJSONBのマッチングと交差の問題について
-
Centos環境でのPostgresqlのインストールと設定、環境変数の設定Tips
-
Postgresqlの高度なアプリケーションは、セルのアイデアをマージするの詳細
-
postgresqlにおける時間処理のコツ(推奨)
-
PostgresqlのデータベーステーブルのデータをExcel形式にエクスポートする方法(推奨)
-
どのように定期的にLinux上でpostgresqlのデータベースをバックアップする
-
GROUP BY句での定数使用に関するPostgreSQLの特別な制限について説明します。
-
PostgreSQLの自己インクリメント構文使用上の注意点
-
oracle_fdwを介してOracleデータにアクセスするためのPostgreSQLの手順
-
PostgreSQLで時間指定タスクを実装する4つの方法
最新
-
nginxです。[emerg] 0.0.0.0:80 への bind() に失敗しました (98: アドレスは既に使用中です)
-
htmlページでギリシャ文字を使うには
-
ピュアhtml+cssでの要素読み込み効果
-
純粋なhtml + cssで五輪を実現するサンプルコード
-
ナビゲーションバー・ドロップダウンメニューのHTML+CSSサンプルコード
-
タイピング効果を実現するピュアhtml+css
-
htmlの選択ボックスのプレースホルダー作成に関する質問
-
html css3 伸縮しない 画像表示効果
-
トップナビゲーションバーメニュー作成用HTML+CSS
-
html+css 実装 サイバーパンク風ボタン
おすすめ
-
PostgreSQLのURL解決方法
-
postgresのjsonbプロパティの利用について
-
単語をソートするカスタム関数とそれをPostgreSQLで使用する(実装コード)
-
PostgreSQLでバッファキャッシュにデータを読み込む方法
-
Postgresqlのユーザーログインエラーの回数を制限するサンプルコード
-
PostgreSQLでデータの一括インポートのパフォーマンスを向上させるn個の方法を説明します。
-
Postgresql データベース timescaledb timescaledb 問題 大容量データテーブルをスーパーテーブルに変換すること
-
postgresql いくつかのメソッドは、要約の重複するデータを削除する
-
Postgresqlのセルフインクリメントidをキーにした場合の重複問題の解決
-
Postgresqlのシーケンススキップの問題を解決する