DEIM Forum 2019 H3-2

OID を用いた Incremental View Maintenance 方式の PostgreSQL への試験的実装
長田 悠吾†

石井

達夫†

増永

良文††

† SRA OSS, Inc. 日本支社 〒 464–8603 東京都豊島区南池袋 2–32–8†† お茶の水女子大学（名誉教授） 〒 112–8610 東京都文京区大塚 2–1–1
E-mail: †{nagata,ishii}@sraoss.co.jp, ††yoshi.masunaga@gmail.com
あらまし 体現化ビュー（materalized view）はデータベースに格納された実体をもつビューであり，これにより通常のビューよりも高速な応答を可能にしている．一方で，ビューの定義に使用されている実テーブルに更新があった際には，その更新を体現化ビューに適用する必要があり，この再構築を一から行うのではコストが大きいという問題がある．そのため，実テーブルへの変化分に応じた更新のみを実体化ビューに適用する IVM（incremental view maintenance）が研究され，そのためのアルゴリズムが提案されている．これまで，タップルに基づくアプローチやそれより効率的であるとする ID に基づくアプローチが提案されてきた．しかし，ID に基づくアプローチはビューに実テーブルのキーが伝搬されていることを前提としているため，重複したタップルの存在を許すバッグ意味論の下では機能しない．これに対して著者らはタップルに付与された OID（object identifier，オブジェクト識別子）を利用することにより，バッグ意味論の下でも機能する IVM 方式を提案し，オープンソースの RDBMS である PostgreSQL において試験的な実装を行った．
キーワード 体現化ビュー，マテリアライズドビュー，incremental view maintenance，IVM，OID，SQL，バッグ意味論，リレーショナルデータベース，PostgreSQL

1. は じ め に（object identifier，オブジェクト識別子）に着目することにより，バッグ意味論の下でも IVM を実現できる新しいアプローチでリレーショナルデータベースにおけるビュー（view）は，そある「OID アプローチ」（OID-based approach）を提案した [4]．

れを定義するクエリを実体とし，ビューに対する問合せが発生

本稿は，この OID を用いた IVM 方式の，オープンソースのしたときにこのクエリを実行し，その結果をクライアントに返RDBMS である PostgreSQL における試験的な実装について報すものである．一方，体現化ビュー（materialized view，マテリ

告するものである．

アライズドビュー）は問合せの結果が実体としてデータベースに格納されたビューであり，これにより通常のビューよりも高2. Incremental View Maintenance

速な応答を可能にしている．しかしながら，ビュー定義に含ま

2. 1 体現化ビューの定義

れる実テーブルが更新された場合には，体現化ビューに格納さ

SQL が操作の対象とするデータは「リレーション」，つまりれているデータは古いものとなり実テーブルの内容との一貫性

タップルの「集合」ではなく「表」（table），つまり一般に重複が失われる．そのため，実テーブルが更新された後には，体現したタップルの出現を許す「バッグ」（bag）である．そのため，化ビューの内容を更新するメンテナンスが必要となる．ただし，問合せやビュー定義はバッグ意味論のもとで表現される必要が体現化ビューを一から再構築するのはコストがかかるため，それある．その際には，単項演算（重複除去，選択，射影），2 項に代わる効率的な方法が求められる．それが IVM（incremental

演算（和，差，共通，直積，結合），グループ化演算からなる

view maintenance，漸増ビューメンテナンス）である．これまバッグ代数（bag algebra, BA）が使用される [5], [6]．このとき，

で多くの IVM 研究・開発が報告されてきているが [1], [2]，こバッグ代数表現は実テーブル群に対して，これらの演算を再帰れまでのタップルアプローチ（tuple-based approach）に代わっ的に適用して定義される．

て，最近 ID アプローチ（ID-based approach）が提案され，そここで，体現化ビューを (Qv , T v ) と表す．Qv はビューを定義

れがタップルアプローチと比較してより効率的であると報告さする問合せ（BA 表現）であり，T v はこの時点で体現化されたれている [3]．しかしながら，ID アプローチは，実テーブルにビューの内容を表す．従って，D をその時点でのデータベース

キーが存在し，かつ体現化ビューにそのキーが伝搬し含まれての状態とすれば T v = Qv (D) となる．添え字の v はビューを意いなければならないという制約があるため，テーブルに重複し味する．

た行の存在を許す「バッグ意味論」のもとでは機能しないとい2. 2 IVM の定義

う欠点を有する．著者らはこの問題を解決するために，リレー

実テーブルに更新があった場合，その体現化ビューをメンテ

ショナル DBMS がテーブルの行を生成する際に付与する OID

ナンスする原始的な方法は，更新された実テーブルを使って，改両アプローチの大きな違いは，この差分テーブルをどのように体現化ビュー V に反映するかである．
【タップルアプローチの場合の V の差分】
体現化ビューのどのタップルをどう更新しないといけないか，を指示するための差分（diﬀs）は次のテーブルで表される．なぜならば，体現化ビュー V の主キーが { 製品名，部品番号 } であるからである．
図 1 IVM の定義

製品名

部品番号

G1

P1

10

11

G2

P1

10

11

δu (V)：

めて一からビューを再構築することであるが，この処理はページへのアクセスや CPU のコストが大きい．実際には，実テーブ
ルの中で更新される行はテーブル全体のごく一部だけのことがほとんどである．そのために，更新により実テーブルに発生した変化分，すなわち，削除される行や追加される行に着目して，旧価格 新価格【ID アプローチの場合の V の差分】
一方，ID アプローチの場合，更新のあった実テーブル商品の主キーが体現化ビュー V にそのまま伝搬しているので，V に対して発行されるべき差分は次のテーブルでよい．

データベースに格納されている体現化ビューのうち，実テー
ブルの変化分に対応した一部だけを更新することで，体現化δu (部品)：

部品番号

ビューのメンテナンスを行うことを考える．この体現化ビューのメンテナンス方法は IVM（incremental view maintenance）と呼ばれる．

(Qv , T v ) を体現化ビューとするとき，IVM の定義は図 1 に示
す通りである [2]．データベース D に更新 δD が掛ったとき，更新後の体現化ビューの状態 Qv (D′ ) を一からの再計算により求めるのではなく，T v に対する変化分 δT v を求め，これを T v に適用することで新しい体現化ビューの状態 T v′ を求める方法を問題にするのが IVM である．
こ こ で タップ ル ア プ ロ ー チ と ID ア プ ロ ー チ の 比 較 を 行
う [3], [4]．
【例題 1】2 つの実テーブル製品と部品，そして体現化ビュー

ID アプローチはビューに実テーブルのキーが伝搬されていている．そのため，更新のあった実テーブルのキーが体現化
ビューに伝搬していなければ ID アプローチは機能しない．このことを，例題 2 で確認する．
【例題 2】実テーブル納品を次のようにする．ここに，納品
名は商品番号から決定できるが，単価は商品番号によらない．
これは例えば，大口顧客には単価を安くしたいといった状況を想定している．
顧客名

商品番号

C1

I1

テレビ

20

C1

I2

冷蔵庫

30

C2

I1

テレビ

22

C2

I2

冷蔵庫

30

納品：

CREATE MATERIALIZED VIEW V AS
SELECT 製品名，部品番号，価格
FROM 製品 NATURAL JOIN 部品

P1

G3

P2

部品番号

価格

P1

10

P2

P20

部品：

ように定義する．

CREATE MATERIALIZED VIEW 卸値 (商品番号，単価)
AS

製品名 部品番号

V：

価格

G1

P1

10

G2

P1

10

G3

P2

20

SELECT 商品番号，単価 FROM 納品

その結果，次のような体現化ビューができあがる．本論文ではバッグ意味論の下で IVM を論じているため，重複したタッ
プルはそのまま表れる．従って，タップルを一意に特定できるキーは存在しない．

このとき，実テーブル商品の部品 P1 の価格が 10 から 11 に

商品番号 単価更新されたとする．この更新 u による実テーブル商品に対する差分テーブルは次のようになる．

δu (部品)：

部品番号P1

商品名 単価このとき，体現化ビュー 卸値＝π{ 商品番号，単価 } (納品) を次の

製品名 部品番号

G2

11

ることが条件となっており，そのキーに基づいてに IVM を行っ

品番号 }，部品の主キーは { 部品番号 } である．

P1

10

2. 4 ID アプローチの問題点

V を次のように定義する．ここに，製品の主キーは { 製品名, 部

G1

P1

テーブルの主キーは { 顧客名, 製品番号 } である．ただし，商品

2. 3 タップルアプローチ vs ID アプローチ

製品：

旧価格 新価格

卸値：
旧価格 新価格

10

11

I1

20

I2

30

I1

22

I2

30

ここで，大口顧客である C1 に対しては商品番号 I2 の卸値を30 から 29 に引き下げたいという想定のもと，以下の更新要求
w を発行したとする．
w: UPDATE 納 品 SET 単 価 ＝ 29 WHERE

顧客名＝

C1

AND 商品番号＝ I2
このとき，以下のことが観察される．

図 2 OID 顕在化と OID 潜在化【ID アプローチの場合】
ビュー卸値には実テーブル納品のキーが残存しないので，IDが，従来のアプローチは，図 2 の左側の T から V に至る QVアプローチは適用不可能である．

と名付けられたパスで差異の伝搬を計算する．一方，OID アプ【タップルアプローチの場合】

ローチは，図 2 の右側に示すとおり，T に一旦 OID 顕在化を施

実テーブル納品に対して，w という更新がなされたので，納して，OID を含む表現の下で差異 δ の計算を行う．ID アプロー

品テーブルに対する差分 δ 納品は次のとおりである．
w

δw納品 ：

顧客名 商品番号

C2

I2

商品名

単価旧値

単価新値

冷蔵庫

30

29

このとき，ビュー卸値は納品テーブルの商品番号，単価上の射影なので，タップル差分（diﬀ）の変換ルールにより，δw納品 は
次のようなビュー卸値に対する差分 δw卸値 に変換される．

チがキーを用いて体現化ビュー内の差分を適用する対象行を特定したのと同様に，OID アプローチでは OID を用いて差分を適用する．そして，得られた結果に対して OID 潜在化を施すことにより，V に対する所望の差異を求める．

4. OID を用いた IVM の試験的実装
以降では OID を用いた IVM 方式の PostgreSQL における試験的実装について述べる．目的は２つあり，１つは OID アプロー

δw卸値 ：

商品番号I2

単価旧値 単価新値

3029

しかし，この δw卸値 ではビュー卸値の行 (I2, 30) が 2 本とも(I2, 29) に更新されてしまうため，誤った IVM となる．つまり，これまでのアプローチはいずれも機能しない．

チの実現可能性を検証することであり，もう１つは PostgreSQL
においてはまだサポートされていない IVM を実現する方法を検討するためである．現在の PostgreSQL では，体現化ビューのメンテナンスは一からのビューを再構築，すなわち，図 1 で

recomputation と表される方法のみがサポートされている．この操作は体現化ビューのリフレッシュ（refresh）と呼ばれ，以下

3. OID アプローチの SQL コマンドを使用する．

3. 1 OID と は

REFRESH MATERIALIZED VIEW <view name>;

OID アプローチ [4] では，バッグ意味論の下でも ID アプロー
チと同じようにタップルを一意に特定する手段として，OID を

このコマンドが実行されると，ビュー定義のクエリを実行し使用することを提案している．ここで，OID（object identifier，

直すことで view name で指定された体現化ビューの内容が一か

オブジェクト識別子）とはリレーショナル DBMS において各ら再構築される．

行に付与されている行を識別するための値である．OID を付与

4. 1 PostgreSQL における OIDする条件で生成されたテーブルに新しく行が挿入されると，そ上述の通り OID アプローチの理論では、OID 顕在化と OIDの行には DBMS により OID が自動的に付与される．そのため，潜在化という２つの操作が必要とされる．しかし，PostgreSQLOID を使用するとキーを前提としなくともタップルを一意に特では OID は明示的に SELECT 文で指定しない限りはユーザか定することができる．OID は PostgreSQL では 32 ビットの整数

らは見えないシステムカラム（隠しカラム）として実装されてである．

いる．そのため，PostgreSQL においては OID カラムの存在を

3. 2 OID アプローチの理論的枠組み

ユーザが意識する必要はなく，実装にあたっても OID 顕在化，

文献 [4] では OID アプローチの理論的枠組みを提案する中でOID 潜在化という操作を明示的に意識する必要はない．理論とOID 顕在化と OID 潜在化という２つの操作を定義している．実の対応付けを考えた場合には，通常は OID は潜在化された状

テーブル T (A, ..., B) の各行に OID が付与されているとする．こ態にあり，SELECT 文で明示的に OID カラムを指定するときのとき，µ(T ) で T (OID, A, ..., B) を表し，OID を含むタップルに OID 顕在化が行われると考えることができる．

表現を求める操作 µ を OID 顕在化（manifestation）と呼ぶ．一方，µ(T ) を OID を含まない表現 T に戻す操作 λ を OID 潜在化（latentization）と呼ぶ．すなわち，λ(µ(T )) = T である．

4. 2 基本的なアイデア
基本的なアイデアを図 3 の例で説明する．図 3 は実テーブル

devices と parts の JOIN 結果の体現化ビューを表している．そ

上記の定義に基づく OID アプローチのしくみを図 2 に示す．

れぞれの実テーブルとビューの行には，OID が付与されており，

IVM では T に更新 u が施された場合に生じる差異 δu (D) から

実テーブルとビューの OID の対応関係は OID マップ（図中でビュー V に対する差異 δ (V) をどのように求めるかが問われる

は OID map）に保存されている．ここでは，ビューの中で OIDu図 3 OID を用いた IVM 実装の基本的アイデア
図 4 本実装の全体像が 301 の行が，OID が 101 および 201 の行から生成されていることを示している．ここで，parts テーブルの OID が 201 の行が変更された場合， OID map を参照することで ビューにおける OID が 301 の行のみが影響を受けることがわかる．すなわ
ち，再計算が必要なのはこの行だけであり，他の行はそのまま残しておくことができる．

4. 3 本実装の概要
図 4 は本実装で行われる処理の全体像を表している．処理されるタイミングによって，大きく３つの部分に分けることがで

図 5 OID マップ作成の例

きる．
１つ目は「ビューを定義」するときに行われる処理である．
このタイミングでは，クエリの実行結果を体現化ビューに格納

5. 本実装の詳細するのに加えて，ビュー定義に含まれる実テーブルとビューの

5. 1 ビューの定義時の処理

間の行 OID の関連付けを行う OID マップの作成，実テーブル

体現化ビューの定義時に，ビューと実テーブルの行 OID を対応

毎の「差分テーブル」と AFTER トリガの生成，および，体現

づける OID マップが作成される．その対応付けは pg ivm oidmap化ビューを更新するときに実行すべき「クエリスクリプト」のという名前のテーブルに保存される．図 5 にその例を示す．こ生成が行われる．

の例では，体現化ビューの OID が 301 の行が，devices テーブ

２つ目は「実テーブルが更新」された時の処理である．この処理では実テーブルに発生した差分が，それぞれの「差分テーブル」に格納される．

ルの OID が 101 の行と parts テーブルの OID が 201 の行から生成されたことなどが示されている．
また，この時にビューを定義する SELECT クエリが解析さ３つ目は実際に「ビューのメンテナンス」，すなわち，体現化

れ，定義に含まれている実テーブルが抽出される．さらに，各ビューの差分更新を行うときの処理である．この時点で，ビュー

実テーブルに対して，その差分を格納するための「差分テー

定義時に生成しておいた「クエリスクリプト」が実行され，体ブル」が作成される．具体的には，実テーブル１つごとに old

現化ビューの内容が実テーブルの内容と一貫するように更新さと new の２つの差分テーブル作成され，その名前は pg ivm ＜れる．

実テーブルの OID ＞ old（または new）とした．例えば，OID

4. 4 本実装の前提条件

が 1111 の実テーブルの OLD 差分を格納するテーブルの名前は

本実装ではテーブルが行 OID を保持していることを前提とし

pg ivm 1111 old となる．さらに，各実テーブル上には AFTERているが，PostgreSQL では通常通りに作成されたテーブルではトリガが作成される．AFTER トリガにはテーブルに対して更行に OID が付与されない．そのため，実テーブルを CREATE

新クエリが発行されたときに，そのクエリの完了後に実行する

TABLE で定義するときに WITH OIDS オプションを指定する処理を記述することができる．本実装では更新クエリによってか，テーブル定義後に事後に ALTER TABLE 文により WITH

テーブルに発生した差分取得するために AFTER トリガを用い

OIDS オプションを追加することで，行 OID を付与されているている．詳細は 5. 2 で触れる．

必要がある．
同様に体現化ビューにも行 OID が保持されている必要があ
るが，現在の PostgreSQL （PostgreSQL 11）の実装では，体現

その他，体現化ビューを更新するときに実行すべき「クエリスクリプト」が生成され，これは pg ivm query というテーブルに保存される．その内容については 5. 3 で触れる．

化ビューの行が OID を持つことが許可されていない．そのた

5. 2 実テーブルの更新時の処理め，本実装では体現化ビューを定義する SQL コマンドである

実テーブルが更新された時には，そのテーブルに定義された

CREATE MATERIALIZED VIEW 文を改造し WITH OIDS オプ

AFTER トリガが発動する．このトリガの中では，OLD 差分とションを使用可能にすることで，OID を含む体現化ビューを作

NEW 差分が取得され，それぞれ対応する pg ivm ＜実テーブル

成できるようにした．

の OID ＞ old テーブルと，pg ivm ＜実テーブルの OID ＞ new図 6 差分テーブルの例
図 7 体現化ビューに挿入する行の計算（結合ビューの場合）

テーブルに格納される．OLD 差分には，テーブルから削除された行，および，更新によって置き換えられた行の古い内容が含まれる．また，NEW 差分には，テーブルに新しく挿入された行，および，更新によって置き換えられた行の新しい内容が含まれる．例えば，parts テーブル（OID は 2222）の price というカラムの値が 10 から 15 に更新された場合，price の値が 10である古い行の内容は pg ivm 2222 old に，price の値が 15 である新しい行の内容は pg ivm 2222 new に格納される．このとき，対応する行の OID も一緒に格納される（図 6）．
同じ行が複数回更新された場合には，NEW 差分の内容を新しく更新することで対応する．例えば，上記の例に続いて，parts
テーブルの price カラムの値が 15 から 25 に更新された場合には，pg ivm 111 new から price が 15 の行を削除し，代わりにprice が 25 の行を挿入することで，古い更新差分の情報を上書
きする．

6. 動作例と IVM の効果の確認
6. 1 体現化ビューの定義
本 実 装 の 動 作 確 認 に は PostgreSQL 標 準 の ベ ン チ マ ー ク
ツールである pgbench [7] で使用される，２つのテーブル pg-

bench acounts と pgbench tellers を結合した体現化ビューを用いた．
比較のため体現化ビューを２つ定義した．IVM を使用する体現化ビュー mv ivm は以下のように，WITH OIDS オプションを指定することで行 OID を含むように定義した．２つの実テーブルは bid カラムで結合し，WHERE 句には tid カラムの値に条件を指定している．２つの実テーブル pgbench acounts とpgbench tellers も WITH OIDS オプションを用いて OID を含む
よう定義されている．

5. 3 ビューのメンテナンス時の処理
本実装では，体現化ビューの差分更新は以下の SQL コマン
ドの実行時に行う．

CREATE MATERIALIZED VIEW mv_ivm WITH OIDS AS
SELECT a.aid, a.abalance, t.tbalance
FROM pgbench_accounts a

REFRESH MATERIALIZED VIEW
INCREMENTALLY <view name>;

JOIN pgbench_tellers t ON a.bid = t.bid
WHERE t.tid in (1,2,3) ;この INCREMENTALLY というキーワードは本実装におけるPostgreSQL に対する拡張であり，これが指定しているときには比較のため，IVM を用いない通常の体現化ビュー mv normal

IVM がすなわち，view name で指定された体現化ビューの差分を，以下のように WITH OIDS を使用せずに作成した．その他

更新が行われる．一方，これが指定されなかった場合には通常の条件は同じである．

のリフレッシュ，つまり体現化ビューの一からの作り直しが行
われる．

IVM が実行された場合には，ビュー定義時に pg ivm script
テーブル内に生成しておいた「クエリスクリプト」を実行する．
具体的には，まず体現化ビューから「古くなった行」を削除する．例えば，pg ivm 2222 old テーブルに OID が 201 の行が含まれている場合，pg ivm oidmap に保存されている OID マップ
を参照することで，OID 301 の行を体現化ビューから削除すべ
きことがわかる．その後に，体現化ビューに新しい行を挿入する．これは，結合を行うビューの場合，実テーブルと実テーブ
ルの NEW 差分テーブルの結合を実行することで求めることができる．例えば，devices テーブルと parts テーブルを結合するビューの場合，devices テーブルそのものと，parts テーブルのNEW 差分テーブルである pg ivm 2222 new の結合によって生成された行が体現化ビューに新しく挿入すべき行となる（図7）．

CREATE MATERIALIZED VIEW mv_normal AS
SELECT a.aid, a.abalance, t.tbalance
FROM pgbench_accounts a
JOIN pgbench_tellers t ON a.bid = t.bid
WHERE t.tid in (1,2,3) ;テーブルの規模を表す pgbench のスケールファクターは 500を使用した．この場合，pgbench accounts の行数は 50,000,000，

pgbench tellers の行数は 5,000，結果となる体現化ビューの行数
は 300,000 となる．

6. 2 IVM の効果検証
まず，pgbench accounts テーブルの１行のみを更新した場合を検証する．以下の実行結果の中で「Time:」以下に出力されている数値は，各操作の所要時間である．

=# UPDATE pgbench_accounts
SET abalance = abalance + 1 WHERE aid = 1;
UPDATE 1

Time: 9.749 ms=# REFRESH MATERIALIZED VIEW mv_normal;
REFRESH MATERIALIZED VIEW
Time: 39979.546 ms (00:39.980)=# REFRESH MATERIALIZED VIEW INCREMANTALLY mv_ivm;
REFRESH MATERIALIZED VIEW
Time: 537.591 ms
通常の体現化ビュー mv normal で REFRESH MATERIAL-

図 8 pgbench accounts 更新時の IVM 所要時間

IZED VIEW コマンドを使用し通常のリフレッシュを行った場
合，およそ 40 秒の時間を要した．一方で，mv ivm に対して

REFRESH MATERIALIZED VIEW INCREMENTAL コマンドを使用して IVM を行った所，500 ミリ秒ほどで完了し，通常のリフレッシュと比較して高速であることが確認できた．
本実装における IVM が正しく行われていることは以下のク
エリを実行することで確認した．このクエリは，テーブルの差集合を計算する EXCEPT と 和集合を計算する UNION 演算を用いて，2 つの体現化ビュー mv normal, mv ivm の差異の行数を調べている．この行数が 0 行であることは，2 つの体現化

図 9 pgbench tellers 更新時の IVM 所要時間

ビューの内容が同じことを示している．

=# SELECT count(1) FROM (最初に tid = 5 の行を更新しているが，ビューの定義よりこの(SELECT * FROM mv_normal

行は体現化ビューの内容に関わりのない．すなわち，ビュー定EXCEPT SELECT * FROM mv_ivm)

義の WHERE 句では tid IN (1, 2, 3) となっており，tid = 5 の行

UNION ALLは含まれていない．そのため，IVM は行うべき処理がほとんど(SELECT * FROM mv_ivm

なく，500 ms ほどで処理は完了している．

EXCEPT SELECT * FROM mv_normal)) q;
count------0(1 row)
図 8 は，pgbench accounts で更新する行数を 500 から 500,000

一方，tid = 1 の行を更新した場合には，19 秒ほど時間がかかった．

=# UPDATE pgbench_tellers
SET tbalance = tbalance + 1 WHERE tid = 1;
UPDATE 1
Time: 9.201 msまで増やしていった場合に，IVM に要する時間の変化を表している．更新する行はランダムに選択された．横線は，通常のリ=# REFRESH MATERIALIZED VIEW INCREMENTALLY mv_ivm;

フレッシュを行った場合の所要時間を表している．更新する行

REFRESH MATERIALIZED VIEW

数が増えると IVM に要する時間も増える傾向にはあるが，こTime: 19555.446 ms (00:19.555)の状況では IVM は通常のリフレッシュに比べて高速であることが見て取れる．
次に， pgbench tellers テーブルの１行を更新した場合を検証する．

=# UPDATE pgbench_tellerss
SET tbalance = tbalance + 1 WHERE tid = 5;

pgbench tellers の行を更新した時に IVM に時間がかかる理由は，このビュー定義においては pgbench tellers の１行が pg-

bench accounts の全ての行と結合されているためである．図 9のグラフは，pgbench tellers で更新する行数を 1, 2, 3 と増やしていった場合に，IVM に要する時間の変化を表したものである．
横線は，通常のリフレッシュの所要時間を表している．行数を

UPDATE 1増やす毎に IVM の所要時間は大幅に増えていき，tid の値が 1,

Time: 10.007 ms

2, 3 である３行全てを更新した場合には通常のリフレッシュの所要時間を上回っている．これは，OID マップのメンテナンス=# REFRESH MATERIALIZED VIEW INCREMENTALLY mv_ivm;などによる，本実装における IVM のオーバヘッドが現れたも

REFRESH MATERIALIZED VIEWのと推測される．

Time: 512.998 ms

7. お わ り に本実装の動作を検証した結果，ある状況では IVM の効果があるが，IVM を用いることでかえって時間がかかる状況があることが示された．これに対しては，通常のリフレッシュより IVMの方が時間がかかることが事前に推測できるのであれば IVMを使用せず通常のリフレッシュを行うといった工夫が考えられる．PostgreSQL においてクエリの実行計画を生成する際には，コストベースのプランナ（オプティマイザ）を用いて最も推定コストが小さい計画が選択される．これを利用することで通常のリフレッシュと IVM のコストが適切に推定できるのであれ
ば，ビューのメンテナンス時においてよりコストの少ないメン
テナンス方法を選択するという改善があり得る．
また，本実装は検証を目的としてとして極めて簡約に作られているため，現時点では制約が大きい．例えば，ビュー定義としては２つの実テーブルの単純な結合ビューしかサポートしておらず，３つ以上実テーブルがあるビューや，集約やサブクエ
リを含むようなビューには対応できていない．ただし，これらの複雑な体現的ビューにおいて差分を計算する理論的方法は先行研究の累積 [3], [5], [6] があり，これらに基づいたクエリスク
リプトをビュー定義に生成することで対応可能である．

PostgreSQL における実装という観点からは OID を使っていること自体にも課題がある．PostgreSQL では次期バージョン以降で行 OID の廃止が決まっており，WITH OIDS を使ったテー
ブル定義ができなくなるためである．そのため，本実装の方法は少なくともそのままでは PostgreSQL の IVM 実装方としては使用できず，OID に依存しない別の実装方法も検討していく必要がある．
【謝辞】本研究は JSPS 科研費 JP16K00152 の助成を受けたものである．

文

献[1] A. Gupta and I. S. Mumick (ed.), “Materialized Views: Techicniques,
Implementations, and Applications,” The MIT Press, 589p., 1999.
[2] R. Chirkova and J. Yang, “Materialized Views,” Foundations andTrends in Databases 4(4), pp.295-405, 2012.
[3] Y. Katsis, K. W. Ong, Y. Papakonstantinou and K. Keliang Zhao,“Utilizing IDs to Accelerate Incremental View Maintenance,” Proceedings of the 2015 ACM SIGMOD International Conference on
Management of Data (SIGMOD ’15 ), pp. 1985-2000, 2015.
[4] 増永良文，長田悠吾，石井達夫, “OID を用いた新規 Incremental View Maintenance 方式の提案,” WebDB Forum 2018 会議録，DBS–167, No.16, 2018 年 9 月．
[5] T. Griﬃn and L. Libkin, “Incremental Maintenance of Views with
Duplicates,” Proc. ACM SIGMOD 95, pp.328-339, 1995.
[6] 増永良文，長田悠吾，石井達夫, “バッグ意味論のもとでのビュー更新問題の検討−更新意図の外形的推測に基づくアプローチの適用可能性−，” DEIM Forum 2017 会議録, H3-5, 8p. 2017.
[7] PostgreSQL Documentation: 11: pgbench,https://www.postgresql.org/docs/11/pgbench.html, (参 照 2018-0212).