PostgreSQL Internals社内読書会やったらまさかの第2期もあったよ

弊社ジャストシステムは、社内勉強会を奨励しています。業務に関連する（関連しそうな）勉強会は業務扱いです。

エンジニア採用ページの技術への取り組みから引用しますと

TechCOLLEGE
機械学習、リーダブルコード、商品力強化などワークショップ形式で学ぶものから、グロースハック、構文解析、インメモリデータベースなどライトニングトークでの共有など、さまざまな議題で勉強会を開催しています。

多人数単発形式もあれば、少人数定期開催もあり。

1年前に「PostgreSQL篠田の虎の巻」読書会で始めた、社内勉強会復興運動、大臣以外の有志もそれぞれ初めて、定期開催が進んでいる。涙出そうに嬉しい。

— masuda kaz (@masudakz) 2017年3月3日

;

勉強会のうち、2016/3開始でやりきった後、2017/3から第2期もやった「PostgreSQL篠田の虎の巻読書会」について、どんな感じだったのか、社内でこんなこともやってます、という紹介記事にします。

Why

2016/1 に「技術内閣」という部署横断技術施策が始まって、当時データベース大臣していました。

サーバー、Webフロントエンド、データベース、サービスインフラなど、技術領域ごとに「大臣」をおき、技術課題解決・最新技術共有・育成を行っています。

ミッションのうち「育成」でも、何か具体的な目に見える活動をしなくちゃなあ、となって読書会してみようと。

• 進捗がページ数で目に見える
• 業務に近くて他の参加者もくいつきそうな文献がいいな
• 弊社各サービスで使っているのはPostgreSQL
• 自分が読みたい文献なら準備に私用時間使っても心理的コストゼロ
• 無償公開のPostgreSQL Internalsがあるじゃない

Why第2期

最初のtweetしたら、こんなリプライが

@masudakz; 使っていただき有難うございます。更新版もありますので、よろしければご利用ください。https://t.co/1lck2324QH

— Noriyoshi Shinoda (@nori_shinoda) 2017年3月3日

;

わーい。篠田さんご本人だ。
というわけで、PostgreSQL 9.6対応の新版でもう1回やったら参加する？とQiita:Teamで募ったら、複数手があがったのです。

What

• PostgreSQL Internals
• 二つ名が「篠田の虎の巻」
• 篠田典良さん @nori_shinodaの労作
  • 278ページもある
• 日本ヒューレットパッカード社内で公開してもターゲット層が小さくて、あまり読んでもらえなかったというツラい話も
• ならば母数を拡大だ、という英断があって無償一般公開へ
• たまたま同じタイトルで 永安悟史さん@nagayasuの文書もあります
  • PostgreSQL Internals
  • 篠田版が業務でPostgreSQLを使うDBAがターゲット、永安版はRDBMS実装例を学ぶ学生・PostgreSQLの開発者向けかと

Whom

• 2016年の第1期で自分以外に4人
• 2017年の第2期で3人
• こじんまりとやりました
• ベテランDBAというよりはこれから経験を積もうという層

How

篠田の虎の巻読書会は全7回で本日完走。1回40ページ平均のペースでした。脱落なしで最後までできた。 https://t.co/IwMx88Yk9h

— masuda kaz (@masudakz) 2017年7月12日

;

• 曜日と時刻と会議室をなるべく固定する
  • 習慣化しちゃうと、5〜7回のシリーズものも完走しやすいですね
  • 1回90分で40-50ページを目安に
• 予習なしでその場で読んでもついてこれるペース
  • 疑問をはさんだり、他のページとの関連を入れたり、実務経験を混ぜたり
• 予習してきた人は「その疑問は先に進めば書いてある」というレベルのガイド役
• 某サービスのステージング環境のpostgresql.conf などを参照しながら、この推奨値でよかったっけ？　いやそんな値では使ってなかったはずといったぐあいに、その場で確認

補足や横道の例

SIGHUPとかSystem Vとか

PostgreSQL になる前の　Postgres をやる前の Ingres だと1970年代なので、さらっと古い古い用語が出てきます。負けないで。

Ingres の Wikipediaより
1973年、IBMでSystem Rプロジェクトが始まり、構築中のシステムに関する一連の論文が公表された。バークレーの2人の科学者 マイケル・ストーンブレーカーとEugene Wongはこれを読んでそのコンセプトに惹かれ、リレーショナルデータベース研究プロジェクトを自ら始めることを決意した。

30年後、Google からGoogle File System と Map Reduce の論文が出て、Hadoop Projectが始まって…というのはまた別の話。

SIGHUPがHang Up：回線断から来ているという話をするには、こんな画像を出してくることになる。受話器は掛け吊されるものだった。 pic.twitter.com/Ko6mZGvJNy

— masuda kaz (@masudakz) 2017年4月22日

;

VACUUM

• VACUUM後も「一部のレコードは重複して格納」とあるが、これは単に空き領域でも zero fill してないだけ。80年代はそういうCPU処理までけちっていた。
• Page内部構造も 70年代のIBMの最初のRDMS実装であるSystem Rとよく似ている。
• VACUUM FULL 怖い。FULLと無印では処理が全く違う。新規ファイルを作成して、旧ファイルから順序よく取り出して新ファイルに詰めていく。つまり一時的にはTABLEの2倍のサイズが必要になる。Disk空きが枯渇してしまうと、VACUUM FULLは実行不可能になって詰む。

WAL

• クラッシュ・リカバリの動作概要を理解すると、WALの大事さが腹におちるよね。

統計情報の自動収集

• サンプリング数は、ちゃんとSIGMODの論文参照して決めてるというソースコメントがかっこいい

実行計画

• プランナに、動的計画法（DP）と遺伝的最適化（GEQO）があるとな
• コストの seq_page_cost:random_page_cost=1:4 が既定値。現代はSSDになったから、この既定値の正当性はあやしくなっているよね。IOとCPUの比も違ってくるはず。

来年も

もしも、もしも、PostgreSQL 10 対応の新版が出たら、第3期もやっちゃいましょう。