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

2014年 5月 23日 (金) 16:10:22 JST

鈴木さん

田中です。

ご確認ありがとうございました。
それぞれインラインでコメントします。

みなさま、異なる見解があればコメントをお願いします。

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


②
>[2]バッファストラテジ
>(2)18ページ
>「バッファ管理はclocksweep」となってますが、clocksweepは具体的には何を
>するアルゴリズムでしょうか？
PostgreSQLで限られたメモリリソースが足りなくなった時にどのデータをメモリ上
から追い出すかを決定するアルゴリズムですが説明が不十分でした。
もう少し分かりやすように解説します。

③
>clocksweepアルゴリズムは、今回の主題であるanalyzeに関係あるのでしょうか？
analyzeやvacuumを行うとshared_bufferのメモリを追い出してしまうのでは？という
心配、疑問にお答えするので全く無関係ではありません。また、今回はanalyze.cを通して
コードを読む際のリテラシーを獲得することも目的の一つにおいています。

④
>(3)18ページ、19ページ、20ページ
>「clocksweepにつかうring」とありますが、clocksweepとring-bufferは関係あ
>るのでしょうか？
ここも説明が不十分でした。追記しておきます。通常のclocksweepを使うと必要以上に
メモリからデータを追い出してしまう動作を抑制するためのメモリ管理システムで
あること、補足します。

⑤
>(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コマンドの場合はフルスキャンは
行いません。

⑦
>#事前に総数が分からずとも統計量を求めるための、
>#オンラインアルゴリズムやストリーミングアルゴリズムが流行ってますが、
>#なぜDBのanalyzeではそういったアルゴリズムが使えないのでしょうか？

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


いただいた指摘のうち、②④⑤⑥は資料に反映し、①③は口頭で解説
⑦はQAの準備をしておきます。

以上、よろしくお願い致します。


2014年5月22日 2:28 Suzuki Hironobu <hironobu ＠ interdb.jp>:

> ML管理者兼、(プレでなく、本体の)勉強会主催者です。
>
> >
> https://docs.google.com/presentation/d/1CzcMzdiWmyPFdqHwMEW9BOz2-2rG7m3w_KcM9ZgKM0M/edit?usp=sharing
> >
> > 技術的な内容でお気づきのことがあればご指摘をお願いします。
> >
>
> 資料を読ませていただいて、浮かんだ疑問など。
>
> [1]メモリコンテキスト
> (1)15ページ
> 「メモリリークを避けるための仕組み」とありますが、
> 「ではGC(ガベージコレクション)ではダメなんでしょうか？」という疑問がでます。
> なぜPostgreSQLはメモリコンテキストを使うのでしょうか？
>
>
> [2]バッファストラテジ
> (2)18ページ
> 「バッファ管理はclocksweep」となってますが、clocksweepは具体的には何をす
> るアルゴリズムでしょうか？
> clocksweepアルゴリズムは、今回の主題であるanalyzeに関係あるのでしょうか？
>
> (3)18ページ、19ページ、20ページ
> 「clocksweepにつかうring」とありますが、clocksweepとring-bufferは関係あ
> るのでしょうか？
>
> (4)21ページ
> バッファストラテジで、BAS_VACUUM(256[kbyte]のring-buffer)を選択していま
> すが、
> これの意味するところは何でしょうか？
> ＃通常はBAS_NORMALでring-bufferを使わないわけですが。
>
>
> [4]サンプリングアルゴリズム
> (5)44ページ,45ページ
> 44ページで「表のフルスキャンはしたくない」と書いてますが、
> 45ページで「vacuumで表をフルスキャンしているので」とあります。
> 結局のところ、フルスキャンしているのでしょうか、していないのでしょうか？
>
> #事前に総数が分からずとも統計量を求めるための、
> #オンラインアルゴリズムやストリーミングアルゴリズムが流行ってますが、
> #なぜDBのanalyzeではそういったアルゴリズムが使えないのでしょうか？
>
>
> 以上、
> 読ませていただいたところで思い浮かんだ疑問点です。
>
> _______________________________________________
> 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/20140523/814e7f4b/attachment.html>