[Pg_study 00016] Re: 次回(5/31)のプレ勉強会について

2014年 5月 23日 (金) 19:31:42 JST

回答ありがとうござます。

追加質問とコメントです。


(1)講演時間はどの程度を予定しているでしょうか？
あくまで本講演が主体ですので、せいぜい20分か25分程度しか確保できないので 
すが。
＃前回も30分程度だったはずです。

今回の勉強会会場も大学の教室をお借りしており、大学の先生にわざわざ休日に 
来ていただくことになるので、あまり早い時刻はお願いできない事 情がありま 
す(終了まで長時間の拘束になりますので)。
この点、考慮して頂きたくお願いいたします。


(2)以下、再コメントです。

> ①
>> [1]メモリコンテキスト
>> (1)15ページ
>> 「メモリリークを避けるための仕組み」とありますが、
>> 「ではGC(ガベージコレクション)ではダメなんでしょうか？」という疑問がでます。
>> なぜPostgreSQLはメモリコンテキストを使うのでしょうか？
> GCではガベージコレクトできるタイミングを自分で制御できません。
> 限られたリソース(メモリ)で安定した性能を要求されるデータベースの
> ようなシビアなシステムではGCは適していないと思います。


バルクでメモリを確保して、使い終わったらガサッと捨てるのはありがちなの 
で、メモリリーク対策だけでなく、メモリ「コンテキスト」と言われる側 面の 
説明が必要ではないかと思いました。


主題であるanalyze処理に関する"メモリ"については、
(次に説明する)リングバッファはどこに確保されるのか、(前に説明し 
た)analyzeを実行するプロセスがメモリコンテキストで確保するのは どこか、
このあたりをはっきり区別するとよいと思いました。


> ②
>> [2]バッファストラテジ
>> (2)18ページ
>> 「バッファ管理はclocksweep」となってますが、clocksweepは具体的には何を
>> するアルゴリズムでしょうか？
> PostgreSQLで限られたメモリリソースが足りなくなった時にどのデータをメモリ上
> から追い出すかを決定するアルゴリズムですが説明が不十分でした。
> もう少し分かりやすように解説します。
>
> ③
>> clocksweepアルゴリズムは、今回の主題であるanalyzeに関係あるのでしょうか？
> analyzeやvacuumを行うとshared_bufferのメモリを追い出してしまうのでは？という
> 心配、疑問にお答えするので全く無関係ではありません。また、今回はanalyze.cを通して
> コードを読む際のリテラシーを獲得することも目的の一つにおいています。
> ④
>> (3)18ページ、19ページ、20ページ
>> 「clocksweepにつかうring」とありますが、clocksweepとring-bufferは関係あ
>> るのでしょうか？
> ここも説明が不十分でした。追記しておきます。通常のclocksweepを使うと必要以上に
> メモリからデータを追い出してしまう動作を抑制するためのメモリ管理システムで
> あること、補足します。

講演時間の件もありますし、
ring-bufferとclocksweepは直接は関係ないようなので、
「analyze処理のために小さな領域を確保して、テーブルのページを次々と読み 
込む」
で済むのではないか、と思いました。


> ⑤
>> (4)21ページ
>> バッファストラテジで、BAS_VACUUM(256[kbyte]のring-buffer)を選択してい
>> ますが、これの意味するところは何でしょうか？
>> ＃通常はBAS_NORMALでring-bufferを使わないわけですが。
> まずは④で説明したとおり、必要以上にメモリ上からデータを追い出さない
> ようにするためです。さらにこの256KbytesというサイズはCPUのL2キャッシュを
> 考慮した値が設定されています。丁度前回の早水さんのセッションを追補できるため
> しくみ分科会としては良い教材と思います。資料に説明を加えます。

これも、講演時間を考えて頂きたく。


> ⑥
>> [4]サンプリングアルゴリズム
>> (5)44ページ,45ページ
>> 44ページで「表のフルスキャンはしたくない」と書いてますが、
>> 45ページで「vacuumで表をフルスキャンしているので」とあります。
>> 結局のところ、フルスキャンしているのでしょうか、していないのでしょうか？
> 表現がよくありませんでした。誤解を生まないように修正します。
> PostgreSQL8.3まではvacuum analyzeを行った場合はフルスキャンを
> 行います。8.4以降もしくはanalyzeコマンドの場合はフルスキャンは
> 行いません。

ここから主題であるanalyzeの話ですが：
「結局ver8.3まではフルスキャンしていたのか？、というか何故テーブルのデー 
タ総数がすぐにわからないのか？」
＃横道ですが、analyzeするとvacuumを先に実行しているように
＃読める記述(vacuumして件数が分かる的な)が気になりました。
「『visibilityMapでall visibleなtuplesのpageは読み飛ばす』のなら、その 
pageの統計情報は反映されないのか？」
「vitterアルゴリズムは、このvisibilityMapの影響を受けずに、正確な統計の 
ためのサンプリングを行うのか？それとも単なる乱 択アルゴリズムのひとつな 
のか？」
「analyzeとvacuumが近いとはどういう意味で言っているのか？　どちらもlive 
tuple, dead tupleの判定が必要だから、共通のルーチンを使っているという意 
味？　それとも関数の呼び出しが近いという表層的な意味？」
などなど

会場で聴衆が知りたいであろう事柄について、その答えが見つけにくいと感じま 
した。


> ⑦
>> #事前に総数が分からずとも統計量を求めるための、
>> #オンラインアルゴリズムやストリーミングアルゴリズムが流行ってますが、
>> #なぜDBのanalyzeではそういったアルゴリズムが使えないのでしょうか？
> Vitterアルゴリズムも一種のオンラインアルゴリズムと思いますが、(どなたか
> 間違っていましたらご指摘ください。)実装されていない理由は誰もコードを
> 書いていないからだと思います。しかし、個人的にはサンプリングサイズが
> 正確になるよりもう少しユーザでサンプル数を制御する実装の方が優先順位が
> 高いと感じています。
> ※default_statistics_targetでも調整できますが、ヒストグラムのサイズが
> 大きくなりすぎ、planに時間がかかるようになるのであまり使い勝手がよく
> ありません。
>

これは質問が曖昧でした。そもそもなぜanalyzeが必要なのかという質問で、 
データをinsert, delete, updateするときにオンラインで出来ないかと。余談な 
のでどうでもよいです。
＃森の木の例え話がありましたが、
＃「vitterアルゴリズムなどを使うのは、1パス目で件数取得、
＃2パス目でサンプリングという2パス構成を避けるため」など、
＃パスという単語を使ったほうがエンジニアに分かりやすいと
＃言うつもりのネタフリだっただけで。


以上です。
講演時間についてはご検討ください。