時系列データ／BRINインデックス対応 - KaiGaiの俺メモ
PG-StromにBRINインデックス対応機能を実装してみた。 まずは、以下のEXPLAIN ANALYZEの実行結果をご覧いただきたい。 条件句で参照しているymd列は日付型（date）で、テーブルにデータを挿入する際には意図的に日付順にINSERTを行っている。 postgres=# EXPLAIN (analyze, buffers) SELECT * FROM dt WHERE ymd BETWEEN '2018-01-01' AND '2018-12-31' AND cat LIKE '%bbb%'; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------
GpuNestedLoop - KaiGaiの俺メモ
現時点でPG-Stromが対応しているワークロードは以下の4つ。 全件探索 (GpuScan) 表結合 (GpuHashJoin) 集約演算 (GpuPreAgg) ソート (GpuSort) これに、GPU内の計算処理で使うデータ型や関数が対応しているかどうかで、GPUオフロードできるかどうかが決まる。 だいたいパッと思い付く程度にSQLクエリ処理で重い(CPUバウンドな)ヤツはカバレッジができてきたけれども、一つ大物が残っている。NestedLoop。 どう実装したものかと思っていたが、よいアイデアが浮かんだので備忘録代わりに。 NestedLoopの場合、結合条件が単純な X=Y の形式ではないので、HashJoinやMergeJoinを用いて効率的に処理する事ができない。要はDBの中で総当たりを行う事になるので非常に重い。 今までに実装した上記の4つのロジックでは、PG-Strom
並列Aggregateに向けて - KaiGaiの俺メモ
PostgreSQL Advent Calendar 2014に参加しています。 数日前、SimonがPgSQL-Hackersに面白いパッチを投げてきた。 曰く、 KaiGai, David Rowley and myself have all made mention of various ways we could optimize aggregates. Following WIP patch adds an extra function called a "combining function", that is intended to allow the user to specify a semantically correct way of breaking down an aggregate into multiple steps. Gents, is this what
Custom Executor 試作版 - KaiGaiの俺メモ
現状、PostgreSQLのエグゼキュータを拡張するにはいくつか方法が考えられる。 Executor(Start|Run|End)_hookを使う エグゼキュータ全体を乗っ取る。逆に言えば、一部の処理（例えば集約演算）だけを俺様実装にしたい時には、本体側のコードをコピーするなりしないとダメ。 Foreign Data Wrapperを使う 特定のテーブルスキャンに限定すればアリ。しかし、集約演算やJOIN、ソートといった処理を俺様実装にする用途には使用できない。 ブランチして俺様パッチを当てる まぁ、これならどうにでもできますがね…。 しかし、あまり使い勝手がよろしくない。 例えば、GPUを使って集約演算を1000倍早くしたいと考えても、それを実装するために、モジュール側でエグゼキュータ全体のお守りをしなければならないというのは、全く嬉しくない。 という訳で、プラン木の一部を差し替えて、特
TOASTメカニズム - KaiGaiの俺メモ
PostgreSQLで可変長データ型を扱う時、内部的にはTOASTと呼ばれる機構を利用して、別の隠しテーブルに可変長のデータを格納するようになっている。この時、可変長のデータは適正な長さに分割されて格納されるので、タプル一個あたりのデータ長がブロックサイズを超える事はない。 この辺の処理を見てみたので、後々のためのメモ。本当は LargeObject の格納に使ったり、巨大な Bytea データの一部分を取り出すような関数を実装するために使えないかと思ってみたり。 TOASTテーブルの構造 テーブルを定義すると、こっそりとそのテーブル専用のTOASTテーブルというものが作成される。SQL的に記述すると以下のような構造を持っており、利用者は直接アクセスできない。 CREATE TABLE pg_toast_<relid> ( chunk_id oid, chunk_seq int4, chu
しゅとろ〜む、しゅとろ〜む - KaiGaiの俺メモ
昨年、オタワでTim Child氏の発表を聞いて以来、実装できないものかと思って暖めていたアイデアがある。GPUの処理能力を使って、PostgreSQLの検索処理を高速化できないか？というものである。 特に複雑な計算を含むクエリの場合、Index-Scanに落ちないで、全件スキャンが走ることが往々にしてあるが、こういったケースで有効に作用するのではなかろうか？という着想である。 クリスマス休暇の間、割とまとまった開発時間を取る事ができたので、PostgreSQLのFDW(Foreign Data Wrapper)として動作するモジュールを作成してみた。 モジュールの名前は PG-Strom で、ドイツ風に『しゅとろ〜む』と発音する。 これは GPU の処理単位である Streaming Multiprocessor に由来する。 もちろん、現状のFDWのI/F前提なので、更新は不可能でソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
