問題タブ [vacuum]

Postgres はテーブルの最後にしか列を追加できないため、テーブルの最後に新しい列を追加し、それらを既存の列と等しく設定してから、元の列を削除することで並べ替えを行います。

では、ドロップされた列によって解放されたメモリを PostgreSQL はどうするのでしょうか? メモリを自動的に再利用するので、単一のレコードは以前と同じ量のスペースを消費しますか? しかし、それにはテーブル全体を書き直す必要があるので、それを避けるために、各レコードの周りにたくさんの空白を保持するだけですか?

さて、質問はそれをかなり要約しています。私のデータベース アクティビティは非常に頻繁に更新されるため、プログラムで Vacuum Analyze を発行したいと考えています。ただし、トランザクション内でクエリを実行できないというエラーが表示されます。それを行う他の方法はありますか？

非常に単純な更新ステートメントがあります。

テーブル W には 90 行しかありませんが、各行の losttime 列と state 列は約 10 秒ごとに更新されます。state と losttime のインデックスがあります (プライマリ インデックスと同様)。

大規模なデータベース (つまり、テーブル W ではなく、他のテーブルに多くのエントリがある) を使用すると、クエリが徐々に遅くなることに気付きました。48 時間実行した後、PqAdminIII のクエリ ウィンドウで実行してタイミングを計っていますが、実行に 17 分かかりました。

同じ問題を示している別のテーブルに同様のクエリがあります。

H にはインデックスがありませんが、H(release) にインデックスを付けたり削除したりしてみましたが、動作は変わりません。このクエリは、データベースが 48 時間稼働しており、テーブル H に約 10 万行あるため、27 分かかります。Postgres サーバーでは、クエリの間、スレッドが完全に固定 (CPU 使用率 100%) されるため、ネットワークやディスクなどで競合が発生しているようには見えません。

したがって、大まかに言えば、データベースが約 5 分間期待どおりに実行された後、基本的なメンテナンス関連の UPDATE コマンドの実行に時間がかかり、徐々にすべてが停止するという動作が見られます。2 日目までに、最初は約 100 ミリ秒実行されていた単純なメンテナンス サイクル (少数の更新) を実行するのに 1 時間かかります。パフォーマンスの低下は、データベース内の情報量 (おそらく N^2 など) に非常に比例していることは明らかです。

自動バキュームはデフォルトを使用してオンになっています。私は（再び）マニュアルを読みましたが、私に飛び出したものは何も見当たりませんでした.

ここで頭をかいてます。9.0.1 および 9.0.2 のリリース ノートに関連すると思われるバグ修正はありません。何が起こっているのかを理解するのを手伝ってくれる人はいますか? ありがとう、M

-xxxx-

さて、ここで 2 つの問題が発生する可能性があります。

最初の更新は現在、高速に実行されているようです。何が起こったのかわからないので、VACUUM / ANALYZE またはいくつかの組み合わせをより頻繁に実行する必要があるという前提で先に進みます。なぜ autovacuum がこれをやってくれないのか知りたいです。

2 番目の更新は引き続き低速で実行されます。クエリ プランは、インデックスが効果的に使用されていないこと、および 80k*30k のクロスが発生していることを示唆しています。（皆さんはこの計画の解釈に賛成ですか？）

UPDATE を SELECT に変換できます。

同様の実行時間 (27 分) です。

postgres オプティマイザーを信頼せず、これを行う場合:

その後、クエリは約 500 ミリ秒で実行されます。

この知識を許容できる速度で実行される UPDATE に戻すにはどうすればよいですか? 私の試み：

約 140 秒で実行されます。これは高速ですが、それでも非常に低速です。

ここからどこへ行くことができますか？

-xxxx-

VACUUM ANALYZE は「ルーチン メンテナンス」の一部として追加されました。アプリケーションは、実行中の自動バキュームとは関係なく、約 1 分に 1 回実行します。

また、2 番目のクエリを書き直して、遅いことが知られている NOT IN 句を削除し、「Left Anti-Semi Join」に置き換えました (え?)

2 つの破損したテーブル (1 つのテーブルには 20 行、もう 1 つのテーブルには 140 行あります) を持つ 9.0.1 データベースがあります。テーブルは読み取り/選択操作には問題ないように見えますが、テーブル内の特定の行を更新するとエラー メッセージが表示されます。

エラー: ファイル "base/16384/16485" のブロック 2 を読み取れませんでした: 8192 バイトのうち 0 バイトのみを読み取ってください

2011-04-14 00:15:15 UTC エラー: ファイル「base/16384/16543」のブロック 3 を読み取ることができませんでした: 8192 バイトの 0 のみを読み取ります
2011-04-14 00:15:15 UTC ステートメント: media_status セットを更新しますupdated_at = now() タイムゾーン 'UTC';

ファイルシステム (Linux) で破損したファイルを調べると、ゼロバイトではありません: ll base/16384/16485 -rwx------ 1 postgres postgres 16384 2011-04-07 09:43 base/16384/16485

「vacuum(FULL, VERBOSE)」コマンドを実行したところ、破損 (または少なくとも更新時のエラー) が消えました。「vacuum(FULL)」コマンドがテーブルの破損を修正する/修正できると予想されますか? それは何が起こったのかについての手がかりを提供していますか?

この破損がいつどのように発生したかを判断する方法はありますか?

バックアップを実行してデータベースを別のシステムに移動したため、ファイルシステム レベルのバックアップ (pg_start_backup()、tar -czf...、pg_stop_backup()) 中に発生した可能性があると思われます。ファイルを復元して postgres を開始した後、これらのエラーが発生し始めました。同じ tar アーカイブを使用して複数回復元を試みましたが、結果は同じでした (異なるシステムで)。

ありがとう、ダン

ドライブ容量が限られている組み込みシステムで PostgreSQL を使用しています。これで、DB ドライブがいっぱいになりました。データを削除しても、スペースが解放されないようです。VACUUM FULL を試みましたが、スペースが必要です。最後に残ったインデックスも削除します。

ランダムに物を削除せずにスペースを解放する方法についてのアイデアはありますか? 以前のデータの一部を失うことはできますが、VACUUM FULL を実行するのに十分なスペースがないため、実際にはそれを行うことができないようです。

pgAdmin では、テーブルの統計が古くなっている場合は常に、プロンプトが表示されます。

VACUUM の実行を推奨

テーブル schema.table の推定行数は、実際の行数とは大幅に異なります。このテーブルで VACUUM ANALYZE を実行する必要があります。

autovacuum=off で pgAdmin 3 と Postgres 8.4.4 を使用してテストしました。変更されたテーブルをクリックすると、すぐにプロンプ​​トが表示されます。

Java で Web ベースのシステムを作成しているとしましょう。pgAdmin のようなプロンプトを表示できるように、テーブルが古くなっているかどうかを検出するにはどうすればよいですか?

私のアプリケーションの性質上、従わなければならないいくつかのルールがあります。

1. pg_stats と pg_statistic の特定のテーブルの統計が最新かどうかを知りたいです。

2. postgresql.conf で autovacuum フラグを設定できません。(つまり、自動バキューム フラグはオンまたはオフにすることができます。私はそれを制御できません。自動バキューム フラグがオンかオフか、統計が最新かどうかを確認する必要があります。)

3. 毎回バキューム/分析を実行して最新にすることはできません。

4. ユーザーがテーブルを選択したときに、pg_stats と pg_statistic に反映されていない更新 (ドロップ、挿入、更新など) がこのテーブルにある場合、テーブルが古くなっていることを示すプロンプトを表示する必要があります。

pg_catalog.pg_stat_all_tables のタイムスタンプを解析することでは実現不可能のようです。もちろん、テーブルが以前に分析されていない場合は、last_analyze にタイムスタンプがあるかどうかをチェックして、テーブルが最新かどうかを調べることができます。ただし、この方法を使用すると、既にタイムスタンプがある場合、テーブルが最新かどうかを検出できません。つまり、テーブルに追加する行数に関係なく、pg_stat_all_tables の last_analyze タイムスタンプは常に最初の分析用です (autovacuum フラグがオフであると仮定します)。そのため、「Running VACUUM recommended」プロンプトは初回のみ表示できます。

また、last_analyze タイムスタンプを現在のタイムスタンプと比較することもできません。何日もテーブルが更新されない可能性があります。そして、1 時間に大量の更新が行われる可能性があります。

このシナリオでは、テーブルの統計が最新かどうかを常に確認するにはどうすればよいでしょうか?

私は Postgres 9.0 データベースを持っており、頻繁にデータ ダンプを取りました。

このデータベースには多くのインデックスがあり、ダンプを復元するたびに postgres がバックグラウンド タスクのバキューム クリーナーを開始します(そうですか?)。このタスクは、復元されたダンプのインデックスを再作成するために、多くの処理時間とメモリを消費します。

私の質問は：

1. データベースのデータとそのデータベースのインデックスをダンプする方法はありますか?
2. 方法があれば、努力する価値はありますか (つまり、インデックスを使用してデータをダンプすると、掃除機よりもパフォーマンスが向上します)。
3. Oracle には、「データ ポンプ」コマンドがあり、imp と exp をより高速に処理できます。postgres には似たようなものがありますか?

前もってありがとう、アンドレ

私は GHood を使用して、このパーティション関数の実装の実行を監視しており、バイナリ ツリーが表示されることを期待しています。代わりに、次のツリーを取得します。

Data.Number.Naturalまた、irc の提案に従って、遅延自然数を使用しようとして失敗しました。

使用するVacuum.Cairoと、関数実行の結果だけが完了します。

次の方法のデータベースがあります。

挿入方法は次のとおりです。

testCount() メソッドは次のとおりです。

取得方法は次のとおりです。

これを実行すると、エラーが発生します。

これが私のLogCatです：

いつも助けてくれてありがとう。