SQLを実行するときには、アクセスするテーブルやインデックスの定義を参照しなければなりません。これらの定義は、SQLを実行するたびに参照するので、shared_buffers上のデータベースの共有メモリバッファとは別に、バックエンドプロセスのローカルメモリにキャッシュしています。直接的な定義は、システムカタログの1つのタプルです。このタプルのキャッシュを“カタログキャッシュ”と呼びます。定義を利用しやすいように構造化したものを“リレーションキャッシュ”と呼びます。そして、FUJITSU Enterprise Postgresでは、この2つをまとめて“メタキャッシュ”と呼びます。
メタキャッシュは、性能のために無制限に保持し続けます。そのため、大規模なデータベースになると、1つのバックエンドプロセスがアクセスするテーブルなどが非常に多くなり、それによってバックエンドプロセスが保持するメタキャッシュも大きくなり、多数のバックエンドプロセスのローカルメモリの合算値が現実的なメモリサイズを超えてしまうかもしれません。
これに対して、メタキャッシュをバックエンドプロセス間で共有することで、インスタンス全体でのメタキャッシュを削減する機能が、Global Meta Cache機能です。現在のGlobal Meta Cache機能では、カタログキャッシュだけを共有化しています。そのため、Global Meta Cacheにおけるメタキャッシュとは、現在はカタログキャッシュのことを指しています。
現在のGlobal Meta Cache機能を使用しても、依然として共有できずにローカルメモリに保持する必要があるものは、共有メモリ上のGlobal Meta Cacheにアクセスするための情報（メタキャッシュ管理情報）とリレーションキャッシュです。Global Meta Cache機能を使用しない場合には、カタログキャッシュとリレーションキャッシュをローカルメモリに保持します。このように、ローカルメモリに保持するメタキャッシュを“Local Meta Cache”と呼びます。長時間アクセスしていないLocal Meta Cacheを削除することでサイズを制限する機能が、Local Meta Cache制限機能です。
Global Meta Cache機能とLocal Meta Cache制限機能を併用すると、最も厳格にメモリ消費をコントロールすることができます。もちろん、どちらか一方だけを使用することもできます。
ただし、Global Meta Cache機能は、共有メモリにアクセスするために、数%のオーバーヘッドがあります。また、Local Meta Cache制限機能を用いると、一度保持したメタキャッシュを破棄することがあるので、再度メタキャッシュを保持するためのオーバーヘッドが生じます。そのため、見積もりによってメモリ消費量を許容できないときに、これらの機能を使用することを検討してください。
