Japan PostgreSQL Developer Meetup 1

= Date & Time =
* 27 April, 2016
* 12:00 - 18:00
= Location =
* SHIROKANE | LAUNGE in Tokyo
= RSVPs =
== Developers ==
* Tatsuo ISHHI
* Yugo NAGATA
* Masao FUJII
* Michael PAQUIER
* Kohei KAIGAI
* Taiki KONDO
* Takayuki TSUNAKAWA
* Etsuro FUJITA
* Kyotaro HORIGUCHI
* Tatsuro YAMADA
* Amit LANGOTE
* Msahiko SAWADA
* Yoshifumi MASUNAGA
== Staff ==
* Kaori INABA
* Mark HISADA
* Hitoshi HEMMI
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 14:00：Self-Introduction (5 min each)
* 14:00 - 14:30：What to discuss today?
* 14:30 - 17:00：Unconference style discussion
* 17:00 - 18:00：Off meeting
* 18:00 - ：Hang out ( to be arranged … )
= Agenda =
# AGGREGATION before JOIN - Kohei KAIGAI
# PL/CUDA - Kohei KAIGAI
# Wiser updatable view - Yugo NAGATA
# In-core connection pooling - Tatsuo ISHII
# SSD with GPU (Skipped) - Kohei KAIGAI
# In-core partitioning - Amit LANGOTE
# Stabilization of 9.6 releases - Michael PAQUIER
# Optimizer hint - Tatsuro YAMADA
# PG Con ASIA in Japan - Kaori INABA
# Next meetup - Tatsuo ISHII
= Meeting notes =
== Aggregation before join ==
* JoinとAggregationが含まれるクエリを高速化するアイディア
* 一般的にAggregationをすると行数が減るためAggregationを実施後にJoinをする
** 例えばMasterテーブルでグルーピングする場合、マスターテーブルで集約をかけた後にJoinすることで高速化できる
* 9.6でCommitされたupper-planner pathificationにより実装が可能となった
** これまでsub query plannerの最後で集約するだけだったのがextension, window function, aggregationなどがパス表現できるようになった
* 候補の数が増えてしまうのでPlanningの時間が増えるのでは？
** 一旦ベストパスを作ってしまった上で集約の追加が行われるのでPlanningの実行時間自体は伸びない
* Partitioned tableを適用すると更に高速化できる
** Append on each Partition
** Parallel queryでPartition Tableごと分割実行すると更に有効
** Declarative partitioningの実装が待たれる
== PL/CUDA ==
* Self-defined CUDA function on SQL
* pg-stromにパッケージされている
** ExtensionでGPUに渡すMatrixというデータ型を追加
*** PostgreSQLの関数渡しのコストは高い
*** 共有Memory渡しになっているが、レジスタ渡しにすると早い
*** Matrix sizeの最大は1GB
** CREATE LANGUAGEでPL/CUDAを追加
*** Procedure language
*** 実行時にコンパイル
* In-database analyticsという意味では過去にも行われてきた
** Netezza: FPGA
** Greenplum : multi-node
* リレーショナル完備だけでなく計算完備まで実装する
** SQL2011の思想と整合性が取れている
== Wiser updatable view ==
* 現状、JOIN, UNION, INTERSECT, EXCEPTを含むViewは更新できない
** 実際は更新できるケースがあることを論文で示す
* POC
** inner Joinの等結合のみの実装
** TriggerでExtensionとして実装
* Communityへの提案はこれから実施
** 仕様がSQL標準で決まっていれば議論が通りやすい
** Trigger以外の実装も検討する必要あり
** Plan書換で実装する方法の検討
== In-core connection pooling ==
* BackendをClientからの接続のたびに、作成、消去せずに使い回す
** 認証結果がbackendに渡されるためユーザ名によってbackendを検索する
** description passingを使って再利用のbackendに情報を渡す
** windowsでもできるか？できるはずであるが要調査
* 拡張モジュールが独自の認証情報をなどを持っている場合はbackendが情報を保持している
** extension用に認証情報をCleanupするためのAPIを用意しておいたほうがよい
** 以前はbakendがforkする前に認証が行われていたが現在はfork後に実行されている
* Communityへの提案
** まずは性能が向上することが大前提
*** Overheadはconnect - disconnectにある
** 考えられる議論
*** どのようなClient interfaceをサポートするか？
*** Outside pooling vs In-core pooling？
== Declarative partitioning ==
* 9.6で提案、議論を行ってきたが、次回の9.7の提案を準備している
* これまで何回も提案されてきたが、なぜ、まだ、入っていないのか？
** 機能として分かりやすく議論に参加する人が多くなかなか決まらない
** 多岐にわたる様々な議論が必要な機能である
** 9.6までで議論を積み重ねており、9.7でまずはSyntaxから提案を行っていく
* なぜOracleのsyntaxではだめなのか?
** 基本的に、他のDBで実装しているためPostgreSQLで必要だという議論は成立しない
** PostgreSQLとして必要なDDLを定義するべく議論が行われている
== Stabilization of 9.6 releases ==
* 9.6 betaがリリースされた
** 新しいリリースを安定化することは、新しい機能を提案するのとおなじくらい重要である
** 引き続き、レビュ、バグFix、 Testへの貢献をしよう
** “The most scariest patch”というアンケートへの回答も重要
*** http://www.postgresql.org/message-id/20160418183721.GA338152@alvherre.pgsql
* 9.6の安定化にむけて引き続き協力しましょう
== Optimizer hint ==
* Optimizerが間違ったプランを選択するということがある
** 大抵のケースは統計情報の最新化やSQLの書き換えなどで改善可能である
** ただし、どうしても避けられないケースがある
*** http://www.slideshare.net/PostgresOpen/robert-haadquery-planning-gone-wrong
* hint planの使いどころは確実にある
** 実例としてどうしても避けられないケースで最終手段として利用されている
** Oracleではhint planや他のツールが存在
** EnterpriseDBも似た様なツールを提供している
* コミュニティでのhint planの扱い
** 主要な理由はOptimizerの機能向上が阻害されるためNOT WANTにリストアップされている
** 利用実態と実装が合っていないことに関しては議論の余地がある
*** 過去の議論の結果は必ずしも決定事項ではない
*** Plannerの改善を含めて問題提起し再度議論をしていくことは重要
== PG Conf Asia ==
* 今年１１月に東京で国際カンファレンス（PG Conf Asia）を企画している
* 学術会からの協力も得られるよう提案する
* 海外からの開発者を含めPGConのようなunconferenceを実施したらどうか？
* アジアのコミュニティにも声をかけるとよい
* 今年のPGConでプロモーションを実施したい
== Next meeting ==
* PostgreSQL開発の議論の場が近くにできるのはありがたい
* 開発者が思いをもって活動しているのかがわかりよかった
* 議論の内容をオープンにしていく必要がある
** 一般の方々に参加してもらう様にしたほうが良い
** 今後の実施形式については検討をしていく
*** PG Conf Asiaも良い機会になり得る
** まずは議事録の公開から実する
* 今後も継続してMeetupを実施していく
* PGConの後もう一度Meetupを企画する
back to Japan PostgreSQL Developer Meetup