もう半月過ぎてしまいましたが。
並行参加あり、かつ夜勤前という悪条件（？）でしたが、LT 込みで参加しました（なお夜勤のため途中離脱…）。
オンライン忘年会をしながらの LT 大会、ということで個々について細かく触れませんが、前回の MyNA 会のその後の話あり、壮大（？）なアップグレード話あり、また、途中離脱後に Twitter を眺めると楽しそうな話が続いていたようで、最後まで参加できなかったのが残念でした。
こういうゆるめの集まり（オンラインですが）も良いですね。
なお、わたしは PostgreSQL アンカンファレンスで話した内容の要約バージョンを話しました。
LTのようでLTではない話（誰か教えて） - Speaker Deck
来年は久々にオフラインでお肉を食べながら参加したいです（まあ、オフライン開催は再来年になりそうですかね…）。
前回の MySQL ユーザ会会（MyNA 会）の参加レポートのように間を空けすぎると後々アドベントカレンダー記事書きと重なって悲鳴を上げそうなので、今回は終わってすぐに書きました。
今回はオーディエンスとして参加しようと思っていたのですが、枠が空いたままだったので前回から連続しての登壇参加となりました。
まずは、前回「予告」されていた、澤田さんによる「PostgreSQL のソースコードの読み方」のお話。
ディレクトリ別にどのような機能のコードが保存されているのかについての説明に加え、コードを追う場合の実例を示していただきました。
src/backend がサーバ側のコード
— たいき (Taiki) (@taikik1222) 2020年12月7日
src/bin がクライアントのコード
src/common は、サーバとクライアント共通のコード。#pgunconf
palloc()とmfree()
— holic@もうずっと在宅がいい (@keiya_laurel) 2020年12月7日
ポスグレ版のmalloc()とmfree()的な感じ
親のメモリコンテキストを開放すれば子も開放される
便利だな
#pgunconf
#pgunconf で、澤田さんがPostgreSQLのソースコードを読む上でのソースディレクトリ構造や、どこから読み始めるといい、って話をしてくれてる。これMySQL編もやってほしい＞MySQLコミュニティでソース読める人。
— atsuizo (@atsuizo) 2020年12月7日
同意。
ドキュメントに書いてないもののロックレベルもソースを読めばわかる、と。#pgunconf
— hmatsu47(まつ) (@hmatsu47) 2020年12月7日
（注）ALTER TABLE の種類別にどのようなロックが掛かるかをソースコードで追って確認しました。
次は、あわっちさんの「データマスキング」についてのお話。
性能調査などで本番相当のデータを使いたいが本番データをそのまま使うと個人情報や機密情報の扱いが問題になるのでマスキングを行うのですが、具体的にどんなことを行うの？という話です。
むかしオライリーから本出てたな…と思ったらもう5年前か。
— hmatsu47(まつ) (@hmatsu47) 2020年12月7日
（マスキングは個人情報だけの保護を意図したものではないけど。）https://t.co/RcKyw5plPu#pgunconf
話の最後は「わたしが欲しいマスキング機能」でした。
ロールでマスキングしたデータか生のデータか自動で出し分けてくれれば便利ですよね。 #pgunconf
— まぐろ; BOOTHに技術書典9新刊あり〼; (椎間板ヘルニア) (@tameguro) 2020年12月7日
3 番目はわたしでした。ネタはこれです。
いつものとおり #pgunconf で話す資料を事前アップロード。
— hmatsu47(まつ) (@hmatsu47) 2020年12月2日
（そしていつものとおり当日までに何度か手を入れる。はず。）https://t.co/CZ3n3kno9b
ちょっと前にバズった記事（わたしではなく他の方の、ですが）の一部を元ネタに、主キー（PK）としてシーケンスを使う vs UUIDv4 を使う小実験をしてみたお話しです。
ブログの技術記事、どうしても鵜呑みにしがちだったり（自分の意見と違うと）逆に全否定しがちだったりするわけですが、そうではなく「自分の利用ケースに合わせて採用する技術・手法などを決めましょう」ということを話してみました。
最後は藤井さんの「pg_standby の削除を検討中」についてのお話。
バックアップ用のサーバにデータを複製する方法として、PostgreSQL ではストリーミングレプリケーションよりも古い 8.3 の時代から用意されていた pg_standby ですが、あまり利用されているとは言い難いし PostgreSQL の開発を進めていく上で支障を生じる部分もあるので可能なら削除したい。…というイメージで聞いていました。
pg_standbyを削除すれば、ウォームスタンバイからの昇格、という特殊条件を考慮せずに済むようになり、PostgreSQLの開発が楽になる。 #pgunconf
— たいき (Taiki) (@taikik1222) 2020年12月7日
前述のとおり今回も登壇枠参加でしたが、
ことによって、参加者のみなさまからのフィードバックを受けることができ、新たな知識を得ることができました。
なお、Database Internalsという書籍ではこの辺りの問題をRight-Only Appendとして紹介してると思う。postgresだとfastpathという機能？があって、リーフの右端に大量にデータが入る処理の最適化をしてるそう。 #pgunconfhttps://t.co/dzDp0VNU8H
— こば（右）- Koba as a DB engineer (@tzkb) 2020年12月7日
UUIDを主キーにするとインデックスの（リーフページをランダムで触るので）full page writesの影響が大きいという記事を昔見た記憶がある。
— Masahiko Sawada (@masahiko_sawada) 2020年12月7日
#pgunconf
（おまけの Export）
「主キーだいしゅきー」がMySQLコミュニティからPostgreSQLコミュニティに輸出？されたｗ #pgunconf
— atsuizo (@atsuizo) 2020年12月7日
…とある事情により、すごく遅くなってしまいました。
当日は、
との並行視聴で、MySQL の Document Store 機能を含む NoSQL の話や、まつもとりーさんの研究開発のお話を聞きながら参加していましたので、個々に感想を話すことができるほど集中していなかったのですが（笑）。
（とかいいつつ最後に LT をねじ込んだりしてますが。）
会を開催された sakaik さんのこちらのブログ記事にもありますが、
「新たな発表者（登壇者）求む！」
というのはわたしも常々感じております。
実際、わたしが住んでいる東海地区にも MySQL やその派生プロダクトのユーザは多いはずなのですが、コロナ前のオフライン勉強会では利用事例や知見の発表をする人がほぼゼロ、という状態でした。
オンラインで勉強会が開催される時代になったので、東京周辺（や福岡）以外の地域からも、どんどんそういう発表をしてくれる人が出てくることを期待しています。
RDBMS にまつわる話、勉強会ネタとしては数年前にすでに「一周」してしまった感があって正直それほど人気があるとは思えないのですが、それゆえ新たにアプリケーション開発や IT システム構築の世界に入ってきた人たちに知見の共有ができていない面もあるように感じています。
結果として「人材不足」になっている面があり（まあ一部で「RDBMS みたいな古の技術からの解放」なんて声があったりしますが、それを言ってる組織が同時に「NoSQL で SQL をサポート！」なんてことをしてるのが面白いところ）、こういうところで登壇を重ねていると、思わぬところからお声が掛かったりする、かも…？（小遣い稼ぎの機運？）
あと PostgreSQL ユーザ会との合同勉強会も。ですね。
（最近、わたしが PostgreSQL アンカンファレンスで話しているネタは、そのあたりのこと × 初心者向けを意識していたりします。）
