COUNT(*) FROM table を実行せずに、テーブルの現在の合計行を取得するためだけにトリガーを作成するのは面倒です。Postgres 8.5 用に計画されているインデックス構成テーブルがそれを可能にするかどうか考えています。
2247 次
2 に答える
3
目に見えるすべてのタプルをカウントするためにスキャンする方が、インデックス構成テーブルの方が必ずしも高速であるとは思いもしませんでした。論理的には、データが B ツリー リーフ ノードにあるか既存のヒープ形式にあるかに関係なく、同じ量のデータを処理する必要があります。
現在、postgresql インデックスは (基本的に) [key,ctid] ペアのみを格納します。(ctid は本質的に "rowid" - ヒープ ページ番号とタプル ライン ポインター インデックス) したがって、タプルごとに [xmin,xmax] をチェックする必要があるため、インデックスを通過するだけではテーブル内の行を数えることはできません。 -- そして、それはヒープ内のデータと共にのみ保持されます。
[xmin,xmax] をインデックスに入れることもできます。これに関する提案が時々出てきます。しかし、これはインデックスを肥大化させ、有用であるためには、すべての更新/削除がそれらが最新に保たれていることを確認する必要があります: そしてそれは問題を引き起こします.テーブルのインデックスの数によって。tsvector などの重いインデックスの場合、またはコストのかかるユーザー式に基づくインデックスの場合、これには時間がかかる可能性があり、いくつかの厄介なケースではまったく機能しません。ヒープ。そして、この演習の要点は、可能であれば、データベースがインデックス内の活性情報のみに依存できるようにすることでした。
オプションで [xmin,xmax] を持つようにインデックスをマークすることが 1 つの可能性だと思います。たとえば、pkey インデックスのみをそのようにマークします。次に、これがいつ有利になるかを把握するために、プランナーの変更が必要になります。これは、かなりの作業のように思えます。
インデックス構成テーブルは、Oracle (およびクラスター化されたインデックスを持つすべてのテーブルが基本的にインデックス構成されている SQL Server) で動作すると私が信じているように機能する場合、代わりに [key,tuple] を主キー インデックスに格納することで機能します (おそらく[key,pkey] 他のすべて) - ctid なし、ヒープなし。したがって、「タプル」には[xmin、xmax、cminmax、natts、....]などが含まれ、インデックスをスキャンするだけで「テーブルからカウント（*）を選択」を満たすことができます。しかし、これは基本的にヒープ上のタプルをスキャンするのと同じです--- 「インデックス」にあるため、魔法のようにスペースを節約することはありません。
AFAICT インデックス構成テーブルの主な理由は、単一の主キー インデックスを持つ小さなテーブルが 3 ページではなく 1 ページを占有し、主キーによるインデックス スキャンが少し高速になる可能性があることです。IOT について私が受けた Oracle 関連のアドバイスは、静的なディメンション テーブルを対象としており、汎用目的ではなく、セカンダリ インデックスの維持にかかるコストが理由の 1 つであるというものだったことを覚えているようです (Oracle ストア [ key,pkey] IOT セカンダリ インデックスではなく、代わりの行 ID のようなものです)。
于 2009-05-19T23:50:31.527 に答える