回答:
ここでのキーワードは次のとおりです。
ポイント1.は低いフィルファクターを示し、2。はその逆です。複数の行バージョンが同じデータページに格納されている場合、パフォーマンスに役立ちます。HOTアップデートはそれを達成します。こちらまたはこちらをお読みください。デッドタプルやfillfactor<100 によって予約されたスペースなど、データページに少し余裕がある必要があります。ただし、更新された列がインデックスに含まれていない場合にのみ機能します。
ここでのもう1つの重要な要素は、タプルのサイズです（ページサイズ（最も一般的には8 kb）との比較）。この関連する回答の詳細：
タプルのサイズが4 kb以上の場合、データページに複数のタプルが存在することはないため、Fill Factorを減らしても無駄です。そのままにしておくこともでき100ます（とにかくデフォルトです）。ただし、一部のデータ型はサイズ制限を超えると「トースト」されて行外に格納されるため、メインリレーションフォークでそれだけ必要なタプルはまれです。
何をするにしても、VACUUM なります頻繁に実行すること。そして、それは一般的に良いことです、私はそれについて心配しません。あなたはたくさんの死んだタプルを作成します。VACUUM開いているトランザクションから見えなくなったデッド行を識別します。マニュアル：
の標準形式は
VACUUM、テーブルとインデックスのデッドローバージョンを削除し、将来の再利用に利用できるスペースをマークします。
大胆な強調鉱山。
あなたはと遊ぶことができる、テーブルごとの設定自動バキュームのためにのみ、このテーブルのために、多くの場合、より少ない（またはそれ以上）、それをトリガします：
デフォルトのしきい値とスケール係数はから取得され ますが、テーブルごとにそれら
postgresql.confを上書きすることができます。
大胆な強調鉱山。特にautovacuum_vacuum_thresholdとautovacuum_vacuum_scale_factor。VACUUM非常に低いのではなく、たくさん走ることは実際には良い考えかもしれませんfillfacter。それはアクセスパターンに依存します。たとえば、すべてのタプルが3時間生存し、それぞれが数回更新される場合でも、fillfactor50のような値に下げます。スイートスポットをテストして見つける必要があります。
これらすべてはさておき、あなたのデータは最初は揮発性のようです：UNLOGGEDテーブルを使用してください：
ログに記録されていないテーブルに書き込まれたデータは、先行書き込みログ（第29章を参照）に書き込まれないため、通常のテーブルよりもかなり高速になります。ただし、クラッシュに対して安全ではありません。ログが記録されていないテーブルは、クラッシュまたは不適切なシャットダウンの後に自動的に切り捨てられます。ログに記録されていないテーブルの内容もスタンバイサーバーに複製されません。
大胆な強調鉱山。サーバーがクラッシュする可能性があり、その後もデータが必要な場合は、これを使用しないでください。しかし、Webアプリケーションのセッションデータについて話している場合、これは許容できる代償となる可能性があります。
または、さらに根本的に：RDBMSによって提供される機能とセキュリティをまったく使用せずに実行できる場合は、RedisのようなKey-Valueストアを使用します。
Key-Value DBMSをお勧めしますが、興味があるためにここに捨てます。
INSERTおよびDELETEステートメントを実行する代わりに、UPDATEのみを実行します。
テーブル構造は次のようになります
ID integer -- sequential ID
Used boolean -- default FALSE
Object -- whatever type is appropriateオブジェクトを保持する列は、分割や行の移動を避けるために固定長になります。オブジェクトを収容し、ディスク上のページを効率的に埋めるために、この列のサイズを変更します。
必要な数の行といくつかの行をテーブルに事前入力します。
オブジェクトを書き込む場合は、Used = Falseの行を見つけて、その行を更新します。オブジェクトを破棄する場合は、Usedを「False」に設定します。ガベージは作成されないため、ガベージコレクションもありません。
もちろん、処理すべき例外条件は多数あります（行のオーバーフロー、テーブルのオーバーフロー、IDの使用に関する競合条件など）が、克服できないものはありません。