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

2014年 5月 25日 (日) 12:37:04 JST

せっなくここまでの大作になったので、
しくみと別の機会でいいので何かPostgreSQLソースコードリーディング的な
イベントを作ってはと思いました。
他のセッションも2,3本用意したりして。

# アンカンファレンスで聴くのもいいかもですが。


2014/05/24 23:01、Kenichiro Tanaka <kenichirotanakapg ＠ gmail.com> のメッセージ:

> 江川さん、みなさま
> 
> 田中です。
> コメントありがとうございます。
> 順序がバラバラですがコメントに回答します。
> 
> >また、それぞれのrelationに対して、どういった処理をするのかは敢えて書いていないのでしょうか？
> ># 外部テーブルはどう扱うのか、スキップする表はないのかなど
> 
> はい。細かな動作は本当に興味がある人は自分で読んでいただき本講義はその
> 下地を作るきっかけになるもにになればいいと思っていました。60分ではanalyze.cの
> 細かな動作までは説明しきれないためです。また、60分、コードを細かく読み上げると
> 眠たくなると思います。そこで、大まかな流れと色々脇道に逸れながら眠たくならなさ
> そうな話題(興味が有りそうな話題)を入れながらのプレゼンを考えていました。
> 
> しかし、先ほど持ち時間が20分と判明しました。。
> 
> ご指摘いただいたところ、可能な限り盛り込んでみたいと思います。
> 
> >あと、技術的な内容ではなくて申し訳ないですが、
> >当日、ホワイトボードで結構ですので、analyzeの大きな作りは
> >フローチャートで示していただけると嬉しいかもしれませんー
> 
> 不安にさせてすみません。本番はもう少し見やすい感じに仕上げます。
> (ペンタブレットを買ったので、これでなんとかならないかと思っています)
> 
> ※前回の江川さんと澤田さんのvacuumのコードのフローはすごく見やすかったです。
> 
> 以上、よろしくお願い致します。
> 
> 
> 
> 
> 
> 2014年5月24日 22:10 江川大地 <daichi.egawa ＠ gmail.com>:
>> 江川です。
>> 
>> 田中さん、参考になる資料、ありがとうございます。
>> ついうっかり、analyze.cを読む休日になってしまいました。
>> 
>> 時間の兼ね合いもありますが、メモリ管理のあたりは軽く触れるくらいにして、
>> 次回の方にメモリマネージャーを読んでもらうとかにしてもいいかもしれませんね。
>> 
>> 些細な指摘で恐縮ですが、、、
>> 
>> 1) 「analyze_rel()を読む」の部分
>> > 6.表の種類(一般の表か、ViewかマテViewか、外部テーブルか)
>> 重箱の隅をつつくようですが、VIEWかまでチェックしてます？
>> 
>> また、それぞれのrelationに対して、どういった処理をするのかは敢えて書いていないのでしょうか？
>> # 外部テーブルはどう扱うのか、スキップする表はないのかなど
>> 
>> > 　7.do_analyze_relを実行する
>> >　8.パーティション表だったらdo_analyze_relを実行する
>> 
>> コードには忠実だと思うのですが、このように書くと、パーティション表の場合もそうでない場合も同じに見えます。
>> 「パーティション表の場合は、（再帰的に）do_analyze_relを実行する」など少し違うということを書くといいのかなと。
>> 
>> 2)「do_analyuze_rel()を読む」 の部分
>> >   9.パーティション表でない場合は統計情報を更新 
>> 
>> これだと、最終的にパーティションに関わるテーブルの場合、まったく統計情報が更新されないように感じてしまいました。
>> もう少し、パーティションの場合の動きをしっかり書くと勉強になりますー
>> 
>> 正直、どのくらいのレベルの方々の集まりになるか分からないのですが、
>> 以下の点も解説されると、どうしてそういうコードになるのか分かっていいと思いました。
>> # 当日、口頭で補うとしてたのかもしれませんが…
>> 
>> 3) なぜデータ型が使える演算子によって、処理が変わるのか
>> 4) なぜサンプルの行数を取得するのか
>> 
>> 
>> 併せて、統計情報を計算するところが、ANALYZEのメインかと思うので、
>> もう少し、教えていただけると嬉しいです(時間があれば、compute_index_stats()にも)w
>> 
>> あと、技術的な内容ではなくて申し訳ないですが、
>> 当日、ホワイトボードで結構ですので、analyzeの大きな作りは
>> フローチャートで示していただけると嬉しいかもしれませんー
>> 
>> 以上です！
>> 
>> 
>> Thanks and Regards,
>> Daichi Egawa
>> 
>> 
>> 2014年5月24日 8:53 Suzuki Hironobu <hironobu ＠ interdb.jp>:
>> 
>>> 一カ所、補足します。
>>> 
>>> 
>>> 
>>>> 
>>>>> ⑤
>>>>>> (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処理に与える 影響は？」
>>> 
>>> などなど、
>>> 定性的な話はもとより、簡単に実験可能な仮説は実際に実験していただいた上で、
>>> その実験方法ふくめて皆で議論するようなレベルにしていきたいと考えています。
>>> #幸い、既に常連さんの多くはそのレベルで話をしているようですが。
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Pg_study mailing list
>>> Pg_study ＠ ml.postgresql.jp
>>> http://ml.postgresql.jp/mailman/listinfo/pg_study
>> 
>> 
>> _______________________________________________
>> Pg_study mailing list
>> Pg_study ＠ ml.postgresql.jp
>> http://ml.postgresql.jp/mailman/listinfo/pg_study
> 
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://ml.postgresql.jp/pipermail/pg_study/attachments/20140525/491b4bf9/attachment-0001.html>