NAKAMURA Minoru の日記 (2016年10月)

[MyWeb] NMINORU.JP のドメイン料を払った

毎年のことだが NMINORU.JP のドメイン料を払う。 もう少し安いレジストラーに引っ越そうと思いながら、ダラダラと今のレジストラーに残っている。 惰性はいかん。 来年こそは移行しよう。

フレッツ光メンバーズクラブのポイントを寄付

フレッツ光に加入していると、フレッツ光メンバーズクラブというのに参加することになり、毎月ポイントが加算される。 このポイントが1600ポイント分溜まっていたので平成28年熊本地震震災義援金に寄付した。 1ポイント=1円なり。

[Movie] スタートレックBEYOND

チネチッタで『スタートレック BEYOND』を観る。 前回の『スター・トレック イントゥ・ダークネス』が2013年なのでちょうど3年経っている。 劇中も3年経過している設定だ。 前作では若々しい印象があった主役陣だが大分老け込んでいる。 スポック大使役だった元祖スポックのレナード・ニモイも亡くなった。 映画の連作を時間をおいて撮るのは難しいね。

クラーナハ展＠国立西洋美術館

上野の国立西洋美術館で開催中のクラーナハ展(国立西洋美術館、展覧会特設サイト)を観てきた。

ルーカス・クラーナハはドイツの画家。 イタリア・ルネサンスから100年ぐらい後、宗教革命の最中の時代を生きた人。 貴族の肖像画がメインだが、アトリエで絵画の大量生産を行い商業的に販売するということをドイツで初めて開始した人らしい。 そのため同じような題材の絵が複数枚あるらしい。 印象主義以前だと一人の画家が描いた絵のうち残存しているものの枚数が少ないので、巡回展をその画家の作品だけで埋められるだけの量がない(版画家は除いて)。 だから「○○とその時代」みたいに他の画家とまとめるか、レオナルド・ダ・ヴィンチ展みたいに習作や絵以外の関連する物品で埋めるしかない。 しかしクラーナハは多作なので、今回の展示の半分ぐらいまでが本人の描いたものだった。

クラーナハというとおっぱいが小さい裸の女性を描くことで有名だが、この展示でもいろいろ拝むことができます。 あとドイツ宗教改革期の宮廷画家で、マルティン・ルーターと親交があり彼の肖像画を多数残しているそうな。教科書に載っているマルティン・ルーターの絵はルーカス・クラナッハの絵がベース。

[Movie] ジェイソン・ボーン

チネチッタで次の予定までに観れる映画として『ジェイソン・ボーン』を観たが、これも続きものの映画だった。 ストーリーの背景が分からない orz

パスポートの更新

パスポートの有効期限が近づいた。 会社都合でパスポートを取得する場合費用は会社持ちなので失効させたままにしておいてもいいのだが、戸籍の取得から始めるといろいろ面倒なので素直に更新する。

というわけで10年ぶり(?)に川崎駅近くのソリッドスクエア内にあるパスポートセンターへ。 手続き自体は20分程度で終わる。 パスポートの受け取りは 14 日以降になるようだ。

追記:10/24

パスポートセンターでパスポートを受け取った。

HPE の Vertica が 8.0 にバージョンアップ

HPE のデータウェアハウス Vertica がメジャーバージョンアップして 8.0 になっていた。

• User-Defined Extension(UDx)を作れるようになった。サンプルがhttps://github.com/vertica/UDx-Examplesで公開されている。
• Machine Learning 関数が強化された。
• COPY_TABLE コマンドが追加され Copy-on-Write テーブルが導入された。
• COPY コマンドで WOS に入れるか ROS に直接入れるかを選択できるようになった。
• Apache Spark 対応がとられ、Spark から Vertica のテーブルへアクセスする Connector が開発された。

CoW テーブルは嬉しい。

[PostgreSQL] PostgreSQL に Magic Sets Rewriting 最適化を導入することをボチボチ考える

SQL のクエリー最適化に Magic Sets Rewriting という手法がある。 元は SQL ではなく Datalog という Prolog 風のクエリー言語で開発された最適化だ。 1986 年に論文が発表されている([1])。

SQL の言葉に翻訳すると、集約を含む相関サブクエリーのあるクエリーを、非相関サブクエリーとの JOIN のあるクエリーに書き換えるというものだ。 元のクエリーが以下のような形だと。

SELECT DEPT.name
       FROM DEPT
       WHERE DEPT.work_stations <
             (SELECT COUNT(EMP.*)
                     FROM EMP
                     WHERE DEPT.name = EMP.dept_name)

最適化された結果は以下のようになる。 実際には SQL として書き換えなくても実行プランが同形になれば十分だ。

SELECT DEPT.name
       FROM DEPT,
            (SELECT EMP.dept_name AS name, COUNT(EMP.*) AS C
                    FROM EMP
                    GROUP BY EMP.dept_name) E
       WHERE DEPT.name = E.name AND DEPT.work_stations < E.C

PostgreSQL 9.5.4 で実験したところ、元のクエリーを効率的な実行プランに書き換えることができないようだ。 DEPT テーブルと EMP テーブルに以下のように適当なダミー値を入れて実行してみた。 結果は元のクエリーの実行は 825 秒かかるが、最適化されたクエリーの実行は 0.35 秒で終わっている。

CREATE TABLE DEPT (name text, work_stations int);
CREATE TABLE EMP (dept_name text);

INSERT INTO DEPT (name, work_stations) SELECT i, i % 10 + 1 FROM GENERATE_SERIES(1, 100000) AS i;
INSERT INTO EMP (dept_name) SELECT i FROM GENERATE_SERIES(1, 100000) AS i;

ANALYZE;

PostgreSQL に並列クエリー実行が入っても、並列化前の実行プランが遅いとどうにもならない。 Magic Sets Rewriting や Sideway Information Passing と呼ばれる最適化をプランナーに入れ込みたいところだ。 南無南無。

• [1] Francois Bancihon, et al, Magic Sets and Other Strange Ways to Implement Logic Programs, PODS '86.