5

コンテキスト

いくつかの一時的な結果をいくつかの一時的なテーブルに保存したいと思います。これらのテーブルは、時間の近くで発生する可能性のあるいくつかのクエリで再利用される可能性がありますが、ある時点で、私が使用している進化的アルゴリズムは、古いテーブルを必要としなくなり、新しいテーブルを生成し続ける可能性があります。それらのテーブルを使用して、場合によっては同時に、いくつかのクエリがあります。これらすべてのクエリを実行するのは1人のユーザーだけです。それがセッションなどのすべてを明らかにするかどうかはわかりませんが、それがどのように機能するかはまだわかりません。

目的

私がやりたいのは、一時テーブルを作成し(まだ存在しない場合)、可能な限りメモリに保存し、ある時点で十分なメモリがない場合は、コミットされるテーブルを削除することです。 HDD(私はそれらが最も最近使用されないだろうと思います)。

クライアントは、さまざまなパラメーターを使用してEMAのクエリを実行し、さまざまな係数を使用してそれらを集約します。各個人は、使用される係数が異なる可能性があるため、EMAのパラメーターは、遺伝子プールに残っているため、繰り返される可能性があります。しばらくすると必要ありません。より多くのパラメータを使用した同様のクエリがあり、遺伝的アルゴリズムがパラメータの正しい値を見つけます。

質問

  • それは「コミットドロップ時」の意味ですか?セッションとトランザクションについての説明を見たことがありますが、それらの概念を本当に理解していません。質問がばかげたらごめんなさい。
  • そうでない場合は、Postgresにこれを実行させる簡単な方法を知っていますか?

回避策

最悪の場合、メモリに保持できるテーブルの数を推測して、自分でLRUを実装しようとすることができるはずですが、Postgresが実行できるほど良くなることはありません。

どうもありがとうございます。

4

1 に答える 1

4

これは複雑なトピックであり、おそらくある程度深く議論する必要があります。PostgreSQLがこれをサポートしていない理由と、最近のバージョンで何をしようとしているのかを説明する価値があると思います。

PostgreSQLには、複数のユーザーにまたがる多様なデータセットをキャッシュするための非常に優れたアプローチがあります。一般に、一時テーブルが非常に大きくなった場合に、一時テーブルをメモリに保持する必要があることをプログラマーが指定できるようにする必要はありません。ただし、一時テーブルは、次の点で通常のテーブルとはまったく異なる方法で管理されます。

  1. 共有バッファではなく、個々のバックエンドによってバッファリングされます

  2. ローカルでのみ表示され、

  3. ログに記録されていません。

これが意味するのは、通常、一時テーブル用に大量のディスクI/Oを生成していないということです。テーブルは通常、WALセグメントをフラッシュせず、ローカルバックエンドによって管理されるため、共有バッファーの使用量に影響を与えません。これは、データがディスクに書き込まれるのはたまにしかなく、他の(通常はより頻繁な)タスクのためにメモリを解放する必要がある場合にのみ行われることを意味します。あなたは確かにディスク書き込みを強制しておらず、何か他のものがメモリを使い果たしたときにのみディスク読み取りを必要とします。

最終的な結果は、これについて本当に心配する必要がないということです。PostgreSQLはすでにある程度、要求されていることを実行しようとしています。一時テーブルのディスクI / O要件は、標準テーブルよりもはるかに低くなっています。ただし、テーブルを強制的にメモリに保持することはありません。テーブルが十分に大きくなると、ページがOSディスクキャッシュで期限切れになり、最終的にはディスクで期限切れになる可能性があります。これは、多くの人が多数の大きな一時テーブルを作成するときにパフォーマンスが適切に低下することを保証するため、重要な機能です。

于 2013-04-20T06:25:51.707 に答える