Re: PGS2_MAX_N_INDEX_CACHE について (Ludia-users 7) - Ludia

岩崎です。


> あわせてお手数をおかけしますが、以下のような認識でよろしいでしょうか？
> 
> ===================================================
> 
> ・検索用テーブル作成
> メリット
> 　一般的な選択肢
> 　メモリ使用量は一定
> 
> デメリット
> 　インデックスが大きくなる
> 
> ===================================================
> 
> ・テーブル分割（継承）
> メリット
> 　SET constraint_exclusion TO on
> 　の状態だと範囲が明確な場合には最低限のメモリで動く（かも）
> 　インデックスの作り直しがしやすい
> 
> デメリット
> 　同時に参照されるとメモリー効率が悪い
> 
> ===================================================

あっていると思います。
ただ、「テーブル分割」のデメリットのところですが、
一度オープンしたインデックスはオープンしっぱなしなので、
「同時に参照」されなくても、いろいろな検索を繰り返しているうちに、
結局全部のインデックスがオープンされて
メモリを消費することになってしまうと思います。
(特にコネクションプーリングでバックエンドプロセスが生き続ける場合)


> とすると
> 
> INITIAL_N_SEGMENTS ：512
> メモリ使用量：１３０M
> 最大インデックスサイズ：８G
> 
> （テーブルを８つに分割）
> INITIAL_N_SEGMENTS ：64
> メモリ使用量：約１６M
> 最大インデックスサイズ：１G
> 
> 上記のような分割も有効なのでしょうか？
> 実際には分割した場合には96や128ぐらいにしそうですが。。。

もう更新されない過去の月次テーブルなどであればそれもありだと思います。
実をいうとINITIAL_N_SEGMENTSを増やしたことはあっても
減らして試したことがないので、、、
もし検証されたら結果を教えていただけるとうれしいです。


-- 
岩崎正剛

Ludia

[Ludia-users 7] Re: PGS2_MAX_N_INDEX_CACHE について