時々私はPostgresクエリを実行しますそれは30秒かかります。次に、すぐに同じクエリを実行します。2秒かかります。Postgresにはある種のキャッシュがあるようです。どういうわけか、そのキャッシュが何を保持しているかを確認できますか？チューニングのためにすべてのキャッシュを強制的にクリアできますか？
注：基本的に、次のSQLServerコマンドのpostgresバージョンを探しています。
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
しかし、そのバッファに実際に何が含まれているかを確認する方法も知りたいです。
助けてくれてありがとう。
回答:
pg_buffercacheモジュールを使用して、PostgreSQLバッファキャッシュの内容を確認できます。「PostgreSQLバッファキャッシュの内部」と呼ばれるプレゼンテーションを行い、表示内容を説明しました。それに伴う情報の解釈に役立つ、より複雑なクエリをいくつか示します。
一部のシステムでは、オペレーティングシステムのキャッシュを確認することもできます。大まかな例については、[pg_osmem.py]を参照してください。
キャッシュを簡単にクリアする方法はありません。Linuxでは、データベースサーバーを停止し、drop_caches機能を使用してOSキャッシュをクリアできます。最初に同期を実行するには、そこで警告に注意してください。
PostgreSQLでキャッシュをフラッシュするコマンドを見たことがありません。表示されるのは、通常のインデックスとデータキャッシュがディスクから読み取られ、メモリに保持されていることです。postgresqlとOSのキャッシュの両方によって。それをすべて取り除くために、私が知っている唯一の方法は次のとおりです。
あなたがすべきことは：
sudo service postgresql stop、sudo systemctl stop postgresql、など）echo 3 > /proc/sys/vm/drop_caches
これにより、OSファイル/ブロックキャッシュがクリアされます。他のOSでそれを行う方法はわかりませんが、非常に重要です。（許可が拒否された場合はsudo sh -c "echo 3 > /proc/sys/vm/drop_caches"、その質問のように試してください）sudo service postgresql start、sudo systemctl start postgresql）drop_cachesに関するGregSmithの回答は非常に役に立ちました。キャッシュを削除するだけでなく、postgresqlサービスを停止して開始する必要があることがわかりました。これがそのトリックを行うシェルスクリプトです。（私の環境はUbuntu14.04とPostgreSQL9.3です。）
#!/usr/bin/sudo bash
service postgresql stop
sync
echo 3 > /proc/sys/vm/drop_caches
service postgresql start
最初は19秒かかり、その後の試行では2秒未満のクエリでテストしました。このスクリプトを実行した後、クエリは再び19秒かかりました。
Linuxボックスで次のコマンドを使用します。
sync; /etc/init.d/postgresql-9.0 stop; echo 1 > /proc/sys/vm/drop_caches; /etc/init.d/postgresql-9.0 start
キャッシュを完全に取り除きます。
postgresqlますが、そうでない場合もあります。
syncサーバーを停止した後、直前に実行する必要があると思いますdrop_caches。
はい、postgresqlには確かにキャッシュがあります。サイズは、shared_buffersの設定によって制御されます。それ以外にも、前の回答で述べたように、OSファイルキャッシュも使用されています。
キャッシュの内容を確認したい場合は、pg_buffercacheと呼ばれるcontribモジュールを使用できます（contrib /のソースツリー、contrib RPM、またはインストール方法に適した場所）。使用方法は、標準のPostgreSQLドキュメントに記載されています。
サーバーを再起動する以外に、バッファキャッシュをクリアする方法はありません。OSがLinuxの場合は、他の回答に記載されているコマンドを使用してOSキャッシュを削除できます。
このエラーが発生しました。
psql：/cygdrive/e/test_insertion.sql：9：エラー：パラメーター53のタイプ（t_stat_gardien）が、プランの準備時のタイプ（t_stat_avant）と一致しません
私は現在の計画をフラッシュすることを探していました、そしてこれを見つけました：
私は私の挿入物の間にこれを持っていました、そしてそれは私の問題を解決します。
DISCARD PLANS;です。また、ドキュメントに記載されているように、「DISCARDはデータベースセッションに関連付けられた内部リソースを解放します」。
はい、共有バッファのpostgresキャッシュとOSキャッシュの両方をクリアすることが可能です。以下のソリューションはWindows用です...他の人はすでにLinuxソリューションを提供しています。
多くの人がすでに言っているように、共有バッファをクリアするには、Postgresを再起動するだけです（サーバーを再起動する必要はありません）。ただし、これを実行してもOSキャッシュはクリアされません。
Postgresが使用するOSキャッシュをクリアするには、サービスを停止した後、優れたSysinternals Suiteの優れたRamMap（https://technet.microsoft.com/en-us/sysinternals/rammap）を使用します。RamMapを実行したら、メインメニューの[空]-> [空のスタンバイリスト]をクリックするだけです。
Postgresを再起動すると、キャッシュがまったくないため、次のクエリが非常に遅くなることがわかります。
Postgresを閉じずにRamMapを実行することもできます。すでに述べたように、共有バッファは通常OSキャッシュと比較してほとんど影響を与えないため、おそらく「キャッシュなし」の結果が得られます。しかし、信頼性の高いテストのために、OSキャッシュをクリアして確認する前に、postgresをすべて停止したいと思います。
注：AFAIK、RamMapを使用するときに「スタンバイリスト」以外の他のものをクリアすることはお勧めしません。他のデータが何らかの形で使用されており、そうすると問題やデータの損失を引き起こす可能性があるためです。postgresファイルだけでなく、他のアプリやOSでも使用されているメモリをクリアしていることを忘れないでください。
よろしく、チアゴL。
キャッシュpg_buffercacheを調べるモジュールがありますshared_buffers。そして、ある時点で、「コールド」キャッシュでいくつかのパフォーマンステストを行うためにキャッシュをドロップする必要があったので、まさにこれを行うpg_dropcache拡張機能を作成しました。チェックアウトしてください。