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

[Suzuki Hironobu]

一カ所、補足します。


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

早水さんの講演は勉強会のレベルを相当底上げしたので、もしもキャッシュの話 
題をもう一度するのであれば、仮説を立てて実験した上で発表すること を皆が 
期待するとおもいますし、我々もそういう人が現れるのを期待しています。そう 
しないと早水さんに講演していただいた意味もないですし。
＃知識よりもattitude(仮説を立て、徹底的に検証する)が重要と
＃いうのが本当の主題だったと思います。


analyzeの文脈でキャッシュの話をするのであれば少なくとも
「(もっとキャッシュが大きなCPUもあるので)ring-bufferのサイズを256kよりも 
大きくしたらanalyzeの実行速度にどの程 度の影響があるのか？　単にシーケン 
シャルスキャンするだけなら、L2キャッシュは関係ないのでは？」

「ドキュメントにはL2キャッシュとあるが、最近のCPUはマルチコアだし、 
キャッシュの関係がもっと複雑。ring-bufferとして確保し た領域が、実際の 
CPU毎にどこに確保されて、どんなアクセスをされるのか、実際に確認する」

「たまたま同じテーブルを、通常のプロセスとanalyzeを実行するプロセスが同 
時にアクセスしたとすると、ring-bufferは共用され るのか？　共用すると仮定 
して、analyzeのプロセスから遠いコアで確保された場合、analyze処理に与える 
影響は？」

などなど、
定性的な話はもとより、簡単に実験可能な仮説は実際に実験していただいた上で、
その実験方法ふくめて皆で議論するようなレベルにしていきたいと考えています。
#幸い、既に常連さんの多くはそのレベルで話をしているようですが。