5

適度に大きい (「大きい」のローカル定義の場合) が、比較的安定したテーブルがあるとします。

今、テーブル全体の内容の何らかの (任意の種類の) チェックサムを取得したいと考えています。

素朴なアプローチは、各行のすべての列の連結のチェックサム (MD5 など) を取得して、テーブル全体を調べてから、おそらくそれらを連結してその MD5sum を取得することです。

クライアント側からは、列の値を MD5 合計ルーチンに徐々に追加し、値を徐々に変更することで、少し最適化される可能性があります。

この理由は、将来のある時点で、データベースに再接続し、他のユーザーがテーブルを変更していないことを確認するためです。これには、INSERT、UPDATE、および DELETE が含まれます。

特定のテーブルに変更が発生したかどうかを判断するより良い方法はありますか? または、より効率的/高速な方法ですか?

更新/説明:

  • テーブル自体を変更することはできません/許可されていません (たとえば、「last-updated-at」列やトリガーなどを追加するなど)。

(これは Postgres 用です。役立つ場合。トランザクション ジャーナルなどを突っ込むのは避けたいと思いますが、そうする方法があれば、私はその考えに反対しません。)

4

4 に答える 4

1

テーブルに何もせずにテーブルが最後にいつ変更されたかを知りたいだけの場合は、データベース サーバー上の実際のファイルのタイムスタンプを調べることができます。

SELECT relfilenode FROM pg_class WHERE relname = 'your_table_name';

正確な場所の詳細が必要な場合は、次を使用できます。

select  t.relname,
        t.relfilenode,
        current_setting('data_directory')||'/'||pg_relation_filepath(t.oid)
from pg_class t
join pg_namespace ns on ns.oid = t.relnamespace
where relname = 'your_table_name';

それは非常に大きなテーブルであると述べたので、それは間違いなくセグメントとトーストに分割されますが、relfilenode を基点として利用し、ls -ltr relfilenode.* または relfilnode_* を実行できます。ここで、relfilenode は実際の上からrelfilenode。

これらのファイルは、そのテーブルで何かが発生した場合、チェックポイントごとに更新されるため、チェックポイントが発生する頻度に応じて、タイムスタンプの更新が表示されます。デフォルトのチェックポイント間隔を変更していない場合は、数分以内です。 .

INSERTS または DELETES が発生したかどうかを確認する別の簡単ではあるが不完全な方法は、テーブルのサイズを確認することです。

SELECT pg_total_relation_size('your_table_name');

ただし、遡及的にする必要がないため、トリガーが問題外である理由は完全にはわかりません。目的が変更されないようにすることである場合、挿入、更新、または削除イベントをキャッチするだけの簡単なトリガーを別のテーブルにルーティングして、試行にタイムスタンプを付けるだけで、実際のテーブルでアクティビティを発生させることはできません。何かが変わったことを知っているだけで、何かが変わることを保証していないようです。

とにかく、これがあなたが抱えているこの奇抜な問題の助けになることを願っています...

于 2013-06-18T21:25:47.130 に答える
1

テーブルの挿入/更新/削除イベントでトリガーを作成するのはどうですか? トリガーは、テーブル変更イベントの時間をマークする別のテーブルにタイムスタンプを挿入する関数を呼び出すことができます。

唯一の問題は、現在テーブルにある同じデータを使用して更新された更新イベントです。テーブルが実際には変更されていなくても、トリガーは起動します。このケースが心配な場合は、更新された行だけに対してチェックサムを生成し、以前に生成されたチェックサムと比較する関数をトリガーで呼び出すことができます。これは通常、テーブル全体をスキャンしてチェックサムするよりも効率的です。

トリガーに関する Postgres ドキュメント: http://www.postgresql.org/docs/9.1/static/sql-createtrigger.html

于 2013-06-18T20:15:53.270 に答える
0

A common practice would be to add a modified column. If it were MySQL, I'd use timestamp as datatype for the field (updates to current date on each updade). Postgre must have something similar.

于 2013-06-18T20:16:07.193 に答える