JP2018014142A - データベース管理システムにおけるマイクロ特化の方法 - Google Patents

データベース管理システムにおけるマイクロ特化の方法 Download PDF

Info

Publication number
JP2018014142A
JP2018014142A JP2017206276A JP2017206276A JP2018014142A JP 2018014142 A JP2018014142 A JP 2018014142A JP 2017206276 A JP2017206276 A JP 2017206276A JP 2017206276 A JP2017206276 A JP 2017206276A JP 2018014142 A JP2018014142 A JP 2018014142A
Authority
JP
Japan
Prior art keywords
bee
code
query
dbms
function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017206276A
Other languages
English (en)
Other versions
JP6491725B2 (ja
Inventor
ケイ． デブライ ソーミヤ
K Debray Saumya
ケイ． デブライ ソーミヤ
ティー． スノッドグラス リチャード
T Snodgrass Richard
ティー． スノッドグラス リチャード
ジャン ルイ
Zhang Rui
ジャン ルイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
University of Arizona
Original Assignee
University of Arizona
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by University of Arizona filed Critical University of Arizona
Publication of JP2018014142A publication Critical patent/JP2018014142A/ja
Application granted granted Critical
Publication of JP6491725B2 publication Critical patent/JP6491725B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2393—Updating materialised views
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24549—Run-time optimisation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

【課題】データベース管理システムにおけるマイクロ特化の方法の提供。
【解決手段】実行時のローカルに不変量変数を識別することに基づいて実行時にＤＢＭＳコードを特化するために、関係およびクエリ特化の情報を利用するためのシステムおよび方法。実行時不変量はしばしば、コードの一部の実行中に一定である値を保持する、コード内の変数の形をとる。マイクロ特化は、元のプログラムから、分岐条件評価においてローカル不変量を参照する分岐文等の不要なコードを排除するために適用される。得られる特化コードは、コードの複雑性を削減するとともに、コード実行中の実行時効率を大幅に向上する。
【選択図】図２

Description

連邦支援の研究に関する記載
本発明は、全米科学財団（ＮＳＦ）によって認められた規約番号ＩＩＳ０８０３２２９およびＣＮＳ０９３８９４８の下で政府の支援を受けて行われた。政府は本発明に所定の権利を有する。
関連出願の相互参照
本出願は、２０１１年１２月２３日出願の米国仮出願第６１／６３０，９９３号の利益を主張し、その開示全体を参照により本明細書に組み入れる。
本発明は、概して、データベース管理のためのシステムおよび方法に関し、より具体的には、データベース管理システム（ＤＢＭＳ）の性能を向上するためのシステムおよび方法に関する。
本明細書の全ての文献は、各々個別の文献または特許出願が参照により組み入れられることが具体的かつ個別に示唆されるのと同様に参照により組み入れられる。以下の説明は、本発明を理解する際に有用であり得る情報を含む。本明細書に提供される情報のうちいずれかが先行技術または本発明に関連すること、あるいは具体的または暗示的に参照されたいずれかの文献が先行技術であるということを承認するものではない。
データベース管理システム（ＤＢＭＳ）は、データの記憶およびアクセスを管理するソフトウェアプログラムの集合体である。近年、さらに大量のデータが生成され、このために記憶され、効率的にアクセスされることが必要になるため、広範囲のアプリケーションドメインにわたってＤＢＭＳが採用されている。過去４０年間にわたるこのような普遍的な配備に推進され、ＤＢＭＳは、これらのドメインに概して適用可能である、わずかなデータモデルに基づいて設計され、エンジニアリングされている。関係データモデルは、商用およびオープンソースのＤＢＭＳによって最も広く採用された１つのモデルである。このデータモデルを効率的にサポートするために、多大な努力が費やされている。
関係データモデルの汎用性に起因して、関係データベース管理システムは、それ自体汎用であり、ユーザが指定するどのようなスキーマ、およびそれらに提示されるどのようなクエリまたは修正も取り扱うことができる。関係演算子は、究極的にあらゆる関係に作用し、下位の関係のあらゆる属性に指定された述語に対処しなければならない。効率的なインデックス構造、革新的な並行処理制御機構、および高度なクエリ最適化戦略等の革新を通じて、現在利用可能な関係ＤＢＭＳは非常に効率的である。このような汎用性および効率性によって、多くのドメインにおける拡散および使用が可能になっている。
データベース管理システム（ＤＢＭＳ）は、最先端のＩＴ基盤構造の礎を形成し、優れた性能を有することが不可欠である。本開示において、ＤＢＭＳに動的なコード特化を適用する機会が提供され、具体的には、クエリ評価中にＤＢＭＳに存在する実行時不変量に注目することによる。クエリ評価は、関係スキーマ、述語の値、結合型に対する広範囲な参照が関与するが、これらは全てクエリ評価中には不変量であり、このために動的な値ベースのコード特化の対象である。
ＤＢＭＳは、任意のスキーマ、クエリ、および修正に対処しなければならないという意味で汎用であることが特筆され、この汎用性は、制御が全てのケースで適切なコードに導かれることを保証する実行時メタデータルックアップおよびテストを使用して実装される。残念なことに、これらのルックアップおよびテストは、これらの演算のうちのいくつかが不必要であることを表す情報が有効である場合でも実行され、不要な実行時オーバーヘッドを招く。
本開示は、実行時にＤＢＭＳコードを特化し、それによってこれらのオーバーヘッドのうちのいくつかを排除するために、関係およびクエリに特化した情報を使用する手法である「マイクロ特化」を導入する。手法および特化時間の分類、ならびに個別のＤＢＭＳ独立モジュールにおいて特化コードシーケンスの作成および実行のほとんどを分離する汎用アーキテクチャが提供される。この手法は、ＤＢＭＳに対する最低限の変更が必要であり、ＴＰＣ−ＨおよびＴＰＣ−Ｃベンチマークの記憶、ＣＰＵ使用量、およびＩ／Ｏ時間という点で、広範囲のクエリ、修正、および一括ロードにわたって同時に性能を向上することができることが示される。また、ＤＢＭＳ開発者が識別されたターゲットコードシーケンスに対してマイクロ特化を適用することを支援する統合開発環境も提供される。
例えば、本願発明は以下の項目を提供する。
（項目１）
データベース管理システム（ＤＢＭＳ）の性能を向上するためにコンピュータによって実装される方法であって、
値が不変量またはクエリ評価ループ内部で値の判定シーケンスをとるクエリの一部を実行する汎用ＤＢＭＳコードにおいて、ローカルに不変量である変数を識別することと、
前記変数がローカルに不変量であることに起因して不要であることを表すＤＢＭＳコードを識別することと、
前記ローカルに不変量である変数に起因して不要であると識別された前記ＤＢＭＳコードを置換するためにマイクロ特化ＤＢＭＳコードを生成することであって、実行されると、前記マイクロ特化ＤＢＭＳコードが、より少ない命令で前記不要なＤＭＳコードと同じ関数を実施する、生成することと、
前記クエリ評価ループの実行中に前記不要なＤＢＭＳコードの代わりに、前記生成されたマイクロ特化ＤＢＭＳコードが実行されるように前記汎用ＤＢＭＳコードを修正することと、を含む、コンピュータによって実装される方法。
（項目２）
前記汎用ＤＢＭＳコードを修正することは、前記汎用ＤＢＭＳコードから前記不要なＤＢＭＳコードを削除することと、前記不要なＤＢＭＳコードを前記マイクロ特化ＤＢＭＳコードへの呼び出しと置換することと、を含む、項目１に記載のコンピュータによって実装される方法。
（項目３）
前記ローカルに不変量である変数を識別することの前に、静的コールグラフを構築することを含む静的解析、および前記クエリ評価グループを表す強力に接続された構成要素を識別するように構成された動的解析によって、前記汎用ＤＢＭＳコードの前記クエリ評価ループを識別することをさらに含む、項目１に記載のコンピュータによって実装される方法。
（項目４）
前記ローカルに不変量である変数は、記憶されたデータ変数または内部データ構造体変数を含む、項目１に記載のコンピュータによって実装される方法。
（項目５）
前記マイクロ特化ＤＢＭＳコードは、特化コードの複数のコピーを含み、各コピーは、前記ローカルに不変量である変数の単一の値に対して特定される、項目１に記載のコンピュータによって実装される方法。
（項目６）
前記マイクロ特化ＤＢＭＳコードは、個別の関係に関連するデータまたは個別のタプル内部に記憶されるデータに基づく、項目１に記載のコンピュータによって実装される方法。
（項目７）
前記マイクロ特化ＤＢＭＳコードは、スキーマに関連するデータに基づく、項目１に記載のコンピュータによって実装される方法。
（項目８）
ローカルに不変量である変数を識別することは、少数の可能な属性値を有する属性を識別するために前記スキーマを解析することを含む、項目７に記載のコンピュータによって実装される方法。
（項目９）
前記ローカルに不変量である変数は、スキーマに指定された態様を含む、項目１に記載のコンピュータによって実装される方法。
（項目１０）
前記態様は、属性の数、属性の型、各固定長の属性の長さ、属性のオフセット、タプル全体またはタプルの１つ以上の属性が圧縮または暗号化されているか、およびタプル全体またはタプルの１つ以上の属性が圧縮または暗号化されている様式、のうちの１つ以上を含む、項目９に記載のコンピュータによって実装される方法。
（項目１１）
前記汎用ＤＢＭＳコードの前記クエリ評価ループの実行中、前記ローカルに不変量である変数は、分岐条件チェックによって評価され、前記マイクロ特化ＤＢＭＳコードを生成することは、前記ローカルに不変量である変数上での前記分岐条件チェックを削除することを含む、項目１に記載のコンピュータによって実装される方法。
（項目１２）
前記ローカルに不変量である変数は、ページが完全または空であるか、およびページ内部のタプル数を含む、特定のページ内部に記憶された情報を含む、項目１に記載のコンピュータによって実装される方法。
（項目１３）
前記ローカルに不変量である変数は、インデックスキー値の型、ページ内の全てのキーによって共有されるプレフィックスの文字数、インデックスページが完全であるか、およびインデックスページがオーバーフローページを有するかを含む、インデックスの特定のページ内部に記憶された情報を含む、項目１に記載のコンピュータによって実装される方法。
（項目１４）
前記ローカルに不変量である変数は、現在のトランザクションが読み出し専用トランザクションであるか、現在のトランザクションがいずれかのページ上でブロックされているか、および現在のトランザクションがコミットされているかを含む、現在のトランザクションに関する情報を含む、項目１に記載のコンピュータによって実装される方法。
（項目１５）
前記ローカルに不変量である変数は、修正が挿入、削除、または更新であるか、および更新の場合、どの特定の列が更新されるかを含む、修正の種類に関する情報を含む、項目１に記載のコンピュータによって実装される方法。
（項目１６）
中間実行可能コードを形成するために前記マイクロ特化ＤＢＭＳコードをコンパイルすることと、
最終実行可能コードを形成するために前記中間実行可能コードを実行時情報で更新することと、
実行時に前記ＤＢＭＳによって前記最終実行可能コードを起動することと、をさらに含む、項目１に記載のコンピュータによって実装される方法。
（項目１７）
前記ローカルに不変量である変数を識別することは、前記ローカルに不変量である変数がローカルに不変量である、前記汎用ＤＢＭＳコードの部分を特定するために、静的データフロー解析を実施することを含む、項目１に記載のコンピュータによって実装される方法。
（項目１８）
前記マイクロ特化ＤＢＭＳコードを実行することによって生じる命令キャッシュミスが抑制されるように前記マイクロ特化ＤＢＭＳコードをメモリ内の専用場所に配置することをさらに含む、項目１に記載のコンピュータによって実装される方法。
（項目１９）
前記汎用ＤＢＭＳコードを修正することは、前記汎用ＤＢＭＳコードから前記不要なＤＢＭＳコードを削除することと、前記不要なＤＢＭＳコードを前記マイクロ特化ＤＢＭＳコードへの呼び出しと置換することとを含み、前記マイクロ特化ＤＢＭＳコードを実行することによって生じる命令キャッシュミスが抑制されるように前記マイクロ特化ＤＢＭＳコードをメモリ内の専用場所に配置することは、仮想空間において前記マイクロ特化ＤＢＭＳコードを起動する関数の隣に前記マイクロ特化ＤＢＭＳコードを配置することを含む、項目１８に記載のコンピュータによって実装される方法。
（項目２０）
前記汎用ＤＢＭＳコードを修正することは、前記汎用ＤＢＭＳコードから前記不要なＤＢＭＳコードを削除することと、前記不要なＤＢＭＳコードを前記マイクロ特化ＤＢＭＳコードへの呼び出しと置換することとを含み、前記マイクロ特化ＤＢＭＳコードを実行することによって生じる命令キャッシュミスが抑制されるように前記マイクロ特化ＤＢＭＳコードをメモリ内の専用場所に配置することは、前記汎用ＤＢＭＳの関数の命令全てを利用可能な命令キャッシュスロットにマッピングすることと、最小の数の命令を含むキャッシュ領域に前記マイクロ特化ＤＢＭＳコードを配置することとを含む、項目１８に記載のコンピュータによって実装される方法。
（項目２１）
中間実行可能コードを形成するために、前記生成されたマイクロ特化ＤＢＭＳコードをコンパイルすることをさらに含む、項目１に記載のコンピュータによって実装される方法。
（項目２２）
最終実行可能コードを生成するために、前記実行可能コードを実行時情報で更新することをさらに含む、項目２１に記載のコンピュータによって実装される方法。
（項目２３）
実行時に前記ＤＢＭＳによって前記最終実行可能コードを起動することをさらに含む、項目２２に記載のコンピュータによって実装される方法。
（項目２４）
前記方法の前記ステップを実施するタイミングは、前記ローカルに不変量である変数に関連する前記情報に依存する、項目２３に記載のコンピュータによって実装される方法。
（項目２５）
データベース管理システム（ＤＢＭＳ）の性能を向上するために構成されるシステムであって、
クエリ評価ループを実施するように実行可能である汎用ＤＭＢＳコードを備えるデータベース管理システム（ＤＢＭＳ）と、
前記ＤＢＭＳに通信可能に連結されたＤＢＭＳマイクロ特化モジュールであって、
その値がクエリ評価ループ内部でローカルに不変量であるクエリの一部を実行する、前記汎用ＤＢＭＳコード内の変数を決定し、
前記ローカルに不変量である変数に起因して不要であると示されるＤＢＭＳコードを決定し、
前記ローカルに不変量である変数に起因して不要であると決定された前記ＤＢＭＳコードを置換するためにマイクロ特化ＤＢＭＳコードを生成し、実行されると、前記マイクロ特化ＤＢＭＳコードが、より少ない命令で前記不要なＤＢＭＳコードと同じ関数を実施し、
前記ＤＢＭＳによる前記クエリ評価ループの実行中に前記不要なＤＢＭＳコードの代わりに前記生成されたマイクロ特化ＤＢＭＳコードが実行されるように前記汎用ＤＢＭＳコードを修正するように構成される、ＤＢＭＳマイクロ特化モジュールと、を備える、システム。
（項目２６）
前記ＤＢＭＳマイクロ特化モジュールは、前記汎用ＤＢＭＳコードから前記不要なＤＢＭＳコードを削除し、前記不要なＤＢＭＳコードを前記マイクロ特化ＤＢＭＳコードへの呼び出しと置換するように構成される、項目２５に記載のシステム。
（項目２７）
前記ローカルに不変量である変数を識別することの前に、前記クエリ評価グループを表す強力に接続された構成要素を識別するように構成された静的コールグラフを構築することを含む、動的解析および静的解析によって、前記汎用ＤＢＭＳコードの前記クエリ評価ループを識別することをさらに含む、項目２５に記載のシステム。
（項目２８）
前記ローカルに不変量である変数は、記憶されたデータ変数または内部データ構造体変数を含む、項目２５に記載のシステム。
（項目２９）
前記マイクロ特化ＤＢＭＳコードは、特化コードの複数のコピーを含み、各コピーは、前記ローカルに不変量である変数の単一の値に特定である、項目２５に記載のシステム。
（項目３０）
前記マイクロ特化ＤＢＭＳコードは、個別の関係に関連するデータまたは個別のタプル内部に記憶されるデータに基づく、項目２５に記載のシステム。
（項目３１）
前記マイクロ特化ＤＢＭＳコードは、スキーマに関連するデータに基づく、項目２５に記載のシステム。
（項目３２）
前記ローカルに不変量である変数は、スキーマに指定された態様を含む、項目２５に記載のシステム。
（項目３３）
前記態様は、属性の数、属性の型、各固定長属性の長さ、および属性のオフセットのうちの少なくとも１つを含む、項目３２に記載のシステム。
（項目３４）
前記汎用ＤＢＭＳコードの前記クエリ評価ループの実行中、前記ローカルに不変量である変数は、分岐条件チェックによって評価され、前記ＤＢＭＳマイクロ特化モジュールは、前記ローカルに不変量である変数上での前記分岐条件チェックを削除するように構成される、項目２５に記載のシステム。
（項目３５）
前記ＤＢＭＳマイクロ特化モジュールは、中間実行可能コードを形成するために前記マイクロ特化ＤＢＭＳコードをコンパイルし、最終実行可能コードを形成するために前記中間実行可能コードを実行時情報で更新するようにさらに構成され、前記ＤＢＭＳは、実行時に前記最終実行可能コードを起動するように構成される、項目２５に記載のシステム。
（項目３６）
前記ＤＢＭＳマイクロ特化モジュールは、前記ローカルに不変量である変数がローカルに不変量である前記汎用ＤＢＭＳコードの部分を特定するために、静的データフロー解析を実施することによって、前記ローカルに不変量である変数を識別するようにさらに構成される、項目２５に記載のシステム。
（項目３７）
前記ローカルに不変量である変数は、ページが完全または空であるか、およびページ内部のタプル数を含む、特定のページ内部に記憶された情報を含む、項目２５に記載のシステム。
（項目３８）
前記ローカルに不変量である変数は、インデックスキー値の型、ページ内の全てのキーによって共有されるプレフィックスの文字数、インデックスページが完全であるか、およびインデックスページがオーバーフローページを有するかを含む、インデックスの特定のページ内部に記憶された情報を含む、項目２５に記載のシステム。
（項目３９）
前記ローカルに不変量である変数は、現在のトランザクションが読み出し専用トランザクションであるか、現在のトランザクションがいずれかのページ上でブロックされているか、および現在のトランザクションがコミットされているかを含む、現在のトランザクションに関する情報を含む、項目２５に記載のシステム。
（項目４０）
前記ローカルに不変量である変数は、修正が挿入、削除、または更新であるか、および更新の場合、どの特定の列が更新されるかを含む、修正の種類に関する情報を含む、項目２５に記載のシステム。
（項目４１）
前記ＤＢＭＳマイクロ特化モジュールは、前記マイクロ特化ＤＢＭＳコードを実行することによって生じる命令キャッシュミスが抑制されるように前記マイクロ特化ＤＢＭＳコードをメモリ内の専用場所に配置するように構成される、項目２５に記載のシステム。
（項目４２）
前記ＤＢＭＳマイクロ特化モジュールは、前記汎用ＤＢＭＳコードから前記不要なＤＢＭＳコードを削除し、前記不要なＤＢＭＳコードを前記マイクロ特化ＤＢＭＳコードへの呼び出しと置換するようにさらに構成され、前記マイクロ特化ＤＢＭＳコードを実行することによって生じる命令キャッシュミスが抑制されるように前記マイクロ特化ＤＢＭＳコードをメモリ内の専用場所に配置することは、仮想空間において前記マイクロ特化ＤＢＭＳコードを起動する関数の隣に前記マイクロ特化ＤＢＭＳコードを配置することを含む、項目４１に記載のシステム。
（項目４３）
前記ＤＢＭＳマイクロ特化モジュールは、前記汎用ＤＢＭＳコードから前記不要なＤＢＭＳコードを削除し、前記不要なＤＢＭＳコードを前記マイクロ特化ＤＢＭＳコードへの呼び出しと置換するようにさらに構成され、前記マイクロ特化ＤＢＭＳコードを実行することによって生じる命令キャッシュミスが抑制されるように前記マイクロ特化ＤＢＭＳコードをメモリ内の専用場所に配置することは、前記汎用ＤＢＭＳの関数の命令全てを利用可能な命令キャッシュスロットにマッピングすることと、最小の数の命令を含むキャッシュ領域に前記マイクロ特化ＤＢＭＳコードを配置することとを含む、項目４１に記載のシステム。
（項目４４）
前記ＤＢＭＳマイクロ特化モジュールは、中間実行可能コードを形成するために、前記生成されたマイクロ特化ＤＢＭＳコードをコンパイルするようにさらに構成される、項目２５に記載のシステム。
（項目４５）
前記ＤＢＭＳマイクロ特化モジュールは、最終実行可能コードを形成するために、前記実行可能コードを実行時情報で更新するようにさらに構成される、項目４４に記載のシステム。
（項目４６）
前記ＤＢＭＳマイクロ特化モジュールは、実行時に前記ＤＢＭＳによって前記最終実行可能コードを起動するようにさらに構成される、項目４５に記載のシステム。
（項目４７）
前記ＤＢＭＳマイクロ特化モジュールは、前記ローカルに不変量である変数に関連する前記情報に依存する場合に前記ステップを実施するようにさらに構成される、項目４６に記載のシステム。
（項目４８）
コンピューティングデバイスのプロセッサによって実行されるとき、前記コンピューティングデバイスに、
値がクエリ評価ループ内部でローカルに不変量であるクエリの一部を実行する、汎用ＤＢＭＳコード内の変数を決定させ、
前記ローカルに不変量である変数に起因して不要であることを表すＤＢＭＳコードを決定させ、
前記ローカルに不変量である変数に起因して不要であると決定された前記ＤＢＭＳコードを置換するためにマイクロ特化ＤＢＭＳコードを生成させ、実行されると、前記マイクロ特化ＤＢＭＳコードが、より少ない命令で前記不要なＤＭＳコードと同じ関数を実施し、
前記ＤＢＭＳによる前記クエリ評価ループの実行中に前記不要なＤＢＭＳコードの代わりに前記生成されたマイクロ特化ＤＢＭＳコードが実行されるように前記汎用ＤＢＭＳコードを修正させる、コンピュータ実行可能命令を含む、持続性コンピュータ可読媒体。
（項目４９）
動的なテンプレートベースの特化を実装するためのコンピュータによって実装される方法であって、
入力タプルの入力源を検証し、複数の分岐のうち、実行する分岐を決定する関数を提供することと、
前記関数を関数テンプレートに変換することであって、前記テンプレートのインスタンス化が前記テンプレートのパラメータとして指定される変数を必要とする、変換することと、
前記関数テンプレートを前記関数の複数のバージョンにコンパイルすることであって、各々が前記複数の分岐のうちの特定の１つに対応する、コンパイルすることと、
実行時中、前記テンプレートのパラメータとして、前記入力タプルの前記入力源を含む関数起動文を介して変数を提供することと、
前記変数を前記関数の正しいバージョンにマッピングすることと、
実行時に前記関数の前記正しいバージョンを起動することと、を含む、コンピュータによって実装される方法。
ＤＢＭＳでマイクロ特化を適用する場所の分類である。 ビーが有効なＤＢＭＳのアーキテクチャを図示する。 ハイブ（Ｈｉｖｅ）実行時環境コールグラフを図示する。 各ＨＲＥ−ＡＰＩ機能が起動されるタイミングを図示する。 クエリを評価する際の関係およびタプルビーの役割を図示する。 クエリ例に対してＰｏｓｔｇｒｅＳＱＬによって生成されるクエリ計画を図示する。 オブジェクトコードのホットスワッピングを示す。 多様なビー配置によるクエリ２２のＬ１ミスのパーセント増加を表すグラフである。 スケールファクタ＝１で、全てのＴＰＣ−Ｈクエリ（クエリ１７およびクエリ２０を除く）に対するＩ１キャッシュミスレートを表すグラフである、 累積キャッシュライン参照ヒストグラムを表すグラフである。 ＴＰＣ−Ｈ実行時間向上を表すグラフである（ウォームキャッシュ、スケールファクタ＝１）。 実行された命令数の向上を表すグラフである（スケールファクタ＝１）。 ＴＰＣ−Ｈ実行時間向上を表すグラフである（コールドキャッシュ、スケールファクタ＝１）。 ＴＰＣ−Ｈ実行時間向上を表すグラフである（ウォームキャッシュ、スケールファクタ＝５）。 実行された命令数の向上を表すグラフである（スケールファクタ＝５）。 ＴＰＣ−Ｈ実行時間向上を表すグラフである（ウォームキャッシュ、スケールファクタ＝１０）。 実行された命令数の向上を表すグラフである（スケールファクタ＝１０）。 ＴＰＣ−Ｈ実行時間向上を表すグラフである（ウォームキャッシュ、スケールファクタ＝１０、ｓｈａｒｅｄ＿ｂｕｆｆｅｒ＝３２ＧＢ、ｗｏｒｋ＿ｍｅｍ＝８ＧＢ）。 実行された命令数の向上を表すグラフである（スケールファクタ＝１０、ｓｈａｒｅｄ＿ｂｕｆｆｅｒ＝３２ＧＢ、ｗｏｒｋ＿ｍｅｍ＝８ＧＢ）。 ｗｏｒｋ＿ｍｅｍパラメータの多様な構成によるクエリ７の評価時間向上を表すグラフである（スケールファクタ＝１０、ｓｈａｒｅｄ＿ｂｕｆｆｅｒ＝３２ＧＢ）。 ｓｈａｒｅｄ＿ｂｕｆｆｅｒパラメータの多様な構成によるクエリ７の評価時間向上を表すグラフである（スケールファクタ＝１０、ｗｏｒｋ＿ｍｅｍ＝８ＧＢ）。 多様な「ビー（ｂｅｅ）」ルーチンを有効にすることによるＴＰＣ−Ｈ実行時間向上を表すグラフである（ウォームキャッシュ、スケールファクタ＝１）。 一括ロードの実行時間性能を表すグラフである。 属性の特化による空間削減を表すグラフである。 ＨＩＶＥの上位アーキテクチャを図示する。 コールグラフビューを含むＥｃｌｉｐｓｅプラグインベースのＨＩＶＥユーザインタフェースを図示する。 ＤＢＭＳにおいてマイクロ特化を適用するためのステップを示すフローチャートである。 不変量変数ハイライトモードにおけるＨＩＶＥの画面例である。 プロファイルされた結果の性能研究ビューを含むＨＩＶＥの画面例である。 ＨＩＶＥ内部の性能研究を表すＨＩＶＥの画面例である。
第１項：導入
１．１ 課題
以下のコードスニペットは、典型的なＤＢＭＳクエリ評価アルゴリズムの構造を例示する。
／＊ｃｏｎｓｔｒｕｃｔ ｄａｔａｂａｓｅ＊／
ｓｃｈｅｍａｓ：＝ＤｅｆｉｎｅＲｅｌａｔｉｏｎＳｃｈｅｍａｓ（）；
ｒｅｌｓ：＝ＰｏｐｕｌａｔｅＲｅｌａｔｉｏｎｓ（ｓｃｈｅｍａｓ）；
／＊ｉｔｅｒａｔｅ ｏｖｅｒ ｑｕｅｒｉｅｓ＊／
ｌｏｏｐ｛
ｑｕｅｒｙ：＝ＲｅａｄＱｕｅｒｙ（）；
ｑｕｅｒｙ ｐｌａｎ：＝ＯｐｔｉｍｉｚｅＱｕｅｒｙ（ｑｕｅｒｙ，ｓｃｈｅｍａｓ）；
／＊ｐｒｏｃｅｓｓ ｑｕｅｒｙ：ｉｔｅｒａｔｅ ｏｖｅｒ ｔｕｐｌｅｓ＊／
ａｎｓ：＝Ｅｘｅｃ（ｑｕｅｒｙ ｐｌａｎ， ｒｅｌｓ， ｓｃｈｅｍａｓ）；
Ｏｕｔｐｕｔ（ａｎｓ）；
｝
データベースは、まず、一連の関係スキーマを定義してから、次いで、これらのスキーマによって指定された関係を投入することによって構築される。スキーマは、関係の名前、属性の数、それらの名前、および型等、各関係に関するメタデータを指定する。この後にクエリ評価が続き、クエリが読み込まれ、クエリ計画がクエリオプティマイザによって生成され、この計画がＳＱＬエンジンによって実行され、取得された応答が出力される。このプロセスが繰り返される。クエリオプティマイザは、実装レベルの決定を行うため（例えば、クエリ内の結合演算はハッシュ結合またはソートマージ結合の実装レベルの演算にマッピングされる場合がある）、かつクエリ演算のための効率的な実行計画を決定するために、データベース内の関係に関するメタデータを使用する。オプティマイザによって生成されるクエリ計画は究極的には、クエリを表すツリーであり、リーフノードがデータベース関係で、内部ノードが演算である。クエリ評価エンジンは、クエリ計画に指定された演算をデータベース内の関係に適用し、関係内のタプルを反復し、スキーマメタデータを使用することで、タプルをパースして属性を抽出し、処理する。
ところが、データモデルによって導入される汎用性は、性能のさらなる向上に対する課題を提示する。タプルの属性にアクセスする場合を検討する。このようなアクセスは、メタデータを参照することが必要である。スキーマを含むカタログは、この抽出された関係内のタプルの各属性値に対してアクセスされなければならない。このカタログルックアップは最適化されているが、そのオーバーヘッドは大量の関係に対してやはり蓄積され、相当のオーバーヘッドとなる。
ＤＢＭＳの実行時挙動の注意深い検証によって、上記のクエリ評価プロセスは、各クエリの評価を通じてローカルで不変量である、いくつかのデータ構造の反復解釈が関与することが明らかになった。例えば、アクセスされなければならない一連の関係は各クエリで一定、すなわち、そのスキーマから取得され、そのタプルをパースするために使用される、そのような関係の属性の種類およびオフセットに関する情報は、クエリの実行を通じて不変量である。しかしながら、関係スキーマ情報は、ＤＢＭＳコードがコンパイルされるときには不明であるため、この情報はクエリ評価コードに伝播することができず、処理される各タプルに対して反復される動作である、スキーマデータの解釈によって取得されなければならない。別の例として、クエリ内の選択または結合演算の表現は、構文ツリーとして表現され、これは、各タプルに対して評価されなければならない。この構文ツリーは、所与のクエリでは一定であり、クエリがＤＢＭＳに対して示された後にのみ明らかになるため、ＤＢＭＳがコンパイルされるときにコード内にコンパイルすることができない。正当なサイズのデータベース内のクエリを処理することは、何百万ものタプルのルックアップが関与する場合があるため、これらの解釈オーバーヘッドは、命令数、ならびに命令キャッシュミスおよびデータキャッシュミスの両方の点で、相当なオーバーヘッドにまで蓄積する可能性がある。
ＤＢＭＳコードの動的特化の機能性は、できる限り多くの不要な実行時オーバーヘッドを削減することを狙いとする。これは、ＤＢＭＳのクエリ評価ループ内の上記のような実行時不変値に対する多数の参照を有する部分を識別し、実際の実行時不変値に特化したコードを動的に生成し、この動的に生成されたコード（へのポインタを）をＤＢＭＳのクエリ評価ループに挿入することによって行われる。特化手法が適用される微細な粒度のため、この手法は「マイクロ特化」と呼ばれる。
１．２ ＤＢＭＳ特化手法
データベース研究コミュニティは、汎用性から生じる非効率性を回避する方式でカスタマイズされたバージョンを提供することによって、ＤＢＭＳの効率を向上するためのＤＢＭＳ特化手法を調査している。ＤＢＭＳ性能を向上する既存の努力のほとんどは、多様なレベルの粒度による特化と特徴付けることができる。アーキテクチャレベルでは、ＤＢＭＳの全体的なアーキテクチャは、アプリケーションのクラスのサポートを向上するように適合される。例として、オンライン解析処理（ＯＬＡＰ）のための列指向ストア、オンライントランザクション処理（ＯＬＴＰ）のためのＨストア、およびストリーム処理ＤＢＭＳが挙げられる。構成要素レベルでは、特定の種類のデータに指向された構成要素がＤＢＭＳに追加される。例として、新しい型の演算子、インデックス、ロックモードが挙げられる。ユーザ規定レベルでは、ユーザは、機能性の特化およびより優れた性能を達成するために、トリガおよびユーザ定義関数を作成する。これらの３つのレベルの特化の欠点は、アーキテクチャ特化の場合は一般的な適用性の欠落、構成要素特化の場合はクエリ最適化、ＤＢＭＳ開発、試験、および保守における複雑性の増加、ならびにユーザ規定特化の場合は複雑なユーザ関与の必要性である。
１．３ クエリコンパイルベースの手法
研究努力の別の流れは、解釈様式におけるクエリの評価ではなく、実行可能コードに対して直接クエリをコンパイルすることに注目する。この種の手法は、クエリコンパイルエンジンによって多数のコード最適化技法が採用され、クエリコンパイル時に適用されることを可能にする。クエリのコンパイルは、ＪＩＴコンパイル技法の形として考えることができ、クエリの実行時特徴を活用することによって生成された実行可能コードの特化を有効にし、これによってコード最適化技法が積極的に利用されることを可能にする。
このクエリコンパイルベースの手法は、特に近年、ＤＢＭＳを稼動しているサーバはしばしば、非常に大型の表を保持するに十分大型のメモリを備えて構成されるということを考慮すると、クエリ性能に顕著な利益を与えることができる。したがって、クエリ評価はしばしば、従来考えられていたようなＩ／Ｏ指向ではなく、ＣＰＵが関係するタスクであり得る。生成されたコードが個別のクエリにカスタマイズされ、これによって、解釈クエリ評価手法よりもはるかに緊密なコード（フットプリントがかなり小さくなる）になるという事実に加えて、別の重要な利点は、生成されたコードが、コンパイラによる所定のＣＰＵのアーキテクチャと緊密に連結するように最適化できることであり、命令キャッシュミスを相当に削減する。
しかし、クエリコンパイル手法は、クエリコンパイラの設計に対する課題を提示する。具体的には、より多くのデータ型および演算子が導入されるので、対応する構成要素がコンパイラ内に追加される必要があり、コンパイラの複雑性の増加となる。より重要な点として、ＪＩＴコンパイルは、プログラムの実行時特徴を観察することによって、コード特化が実行時のみに適用されるように制限する。すなわち、特定のＤＢＭＳの多くの実行時特徴がコンパイル時に識別することができる場合であっても、実行時にコンパイルオーバーヘッドが導入される。例えば、関係スキーマが定義された後、この関係にアクセスするＤＢＭＳ内のコードは、特化をクエリ評価時に延期するのではなく、早ければスキーマ定義時に特化することができる。
１．４ マイクロ特化
本発明の実施形態は、値がクエリ評価ループ内部でローカルに不変量である変数（典型的に、スキーマメタデータまたはクエリ特異定数）を識別することによって、ＤＢＭＳの特定の環境に特異的な情報を利用する。このような変数は、静的に決定される不変量と、さらに高速に変化する変数との間である。そうではなく、このクエリ評価ループの概念、すなわち、実行時不変量（複数可）が存在する、ＤＢＭＳに特定の概念が存在する。このような不変量に関するこの特定の特徴は、頻繁にとられる実行パスに沿って不要な演算子を排除する微細粒度の特化に利用され、小型化および高速化の両方となる、更に最適化されたコードを導く。しばしば、このループは、下位関係（複数可）内のあらゆるタプルに対して評価され、このために、相当な性能向上の可能性を提供する。特化に使用される不変量は実行時のみ有効であるため、このような特化は、静的技法を使用して実行することができず、実行時まで保留されなければならない。これは、特化プロセスそのものが非常に軽量でなければならないことを暗示する。
スキーマメタデータおよびクエリ特異値に基づいた特化に加えて、関係内の値そのものという、動的特化のための別の機会が識別された。このような値が比較的少ない、または比較的共通である場合、このような値の特化は非常に効果的であり得る。革新は、個別の関係に関連するデータ、またはさらに個別のタプル内部のデータに基づいてＤＢＭＳコードを特化することである。
このような微細粒度の下位の動的特化は、前項で検討したような、ＤＢＭＳで有効な他のさらに上位の特化から区別するために、ＤＢＭＳマイクロ特化と呼ばれる。マイクロ特化は、第１．１項に記載したように、値がクエリ評価ループ内部で不変量である（典型的に、スキーマメタデータまたはクエリ特異定数）個別の構成要素内部の変数を識別することによって、ＤＢＭＳの特定の環境に特異的な情報を利用する。この情報は、頻繁にとられる実行パスに沿って不要なコードを排除する微細粒度の特化のために使用され、小型化および効率化両方である最適化されたコードにつながる。しばしば、このループは、下位関係（複数可）のあらゆるタプルに対して評価され、このために、相当な性能向上の可能性を提供する。しかしながら、特化のために使用される不変量は実行時のみ有効であるため、このような特化は、従来のコンパイラ技法を使用して実行することができず、マイクロ特化はＤＢＭＳ実行時に適用される。これは、特化プロセスそのものが非常に軽量でなければならないことを暗示し、様々な重要な技術的課題が生じる。
マイクロ特化は、粒度がもっと粗い特化の不利益を全く発生させない。ＤＢＭＳアーキテクチャは変更されないため、サポートすることができるアプリケーションの範囲を制約しない。マイクロ特化は追加の構成要素を全く追加しないので、ＤＢＭＳの複雑度を増加しない。マイクロ特化はユーザ関与が不要である。さらに、マイクロ特化は、他の３つの形の特化と連携して適用される可能性を有する。例えば、列指向ＤＢＭＳおよびメインメモリベースのＤＢＭＳ、ならびに新しい種類の演算子に直接適用することができる。
１．５ 本開示の構造
本開示において、第２項では、単純なクエリであっても性能を向上する単独のマイクロ特化事例研究が検討される。この事例研究では、特定のコード変更が確認され、性能向上が予想、検証される。第３〜６項では、３つの種類のマイクロ特化を生じる、３つの汎用クラスの不変値を分類して広くマイクロ特化の機会が確認される。次いで、マイクロ特化によって必要な機構をサポートする実行時環境が導入される。この実行時環境の実装およびＰｏｓｔｇｒｅＳＱＬへの組み込みが説明される。本発明では、他の種類のＤＢＭＳも使用されてもよいことを理解されたい。第８項では、ＴＰＣ−ＨおよびＴＰＣ−Ｃベンチマークの包括的な一連の実験を通じて、マイクロ特化の効果およびコストが検討される。第９項では、マイクロ特化を複雑なＤＢＭＳに導入するための開発環境の構造に関する検討が提供される。特化標的をどのように識別するか、適用する特化手法をどのように決定するか、マイクロ特化を有効にするためにＡＰＩへの呼び出しをどのように挿入するかが検討される。第１０および１１項では、より広義の状況のＤＢＭＳにおけるマイクロ特化およびコンパイラベースの特化が説明される。
第２項：事例研究
ＰｏｓｔｇｒｅＳＱＬの下位ソースコード内部からどのようにマイクロ特化の機会が利用されるかを示すための例が最初に提供される。この特定のマイクロ特化の性能メリット解析も提供される。
前項に記載したように、関係スキーマカタログのルックアップは、クエリ評価に対する相当な非効率を提示する。スキーマ特異値を参照する複雑な分岐文を含む関数に適用された単一のマイクロ特化が確認される。このマイクロ特化は小型のクエリであっても性能を向上することが示された。この事例研究において、特異的コード変更が検討され、性能向上が予想され、次いで、予想が実験で検証される。
ＤＢＭＳには、クエリ評価ループ内部でローカルに不変量（定数）であり得る多数の変数が存在する。例えば、関係のスキーマが定義されると、属性の数は定数である。さらに、各属性の型、各固定長属性の長さ、ならびにいくつかの属性（可変長属性によって先行されない）のオフセットはこの関係では定数である。
リスト１は、ＰｏｓｔｇｒｅＳＱＬのソースコードの関数、ｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ（）のスニペットである。この関数は、タプルがフェッチされると必ず実行され、記憶されたタプルからの値をロング整数の配列に抽出する。関数は、各属性を抽出するためにループ（第１１行から開始）に依存する。各属性に対して、タプルの記憶されたバイト内部の属性の値をロング整数に変換するために、コードシーケンス（第１２行〜第４３行）のパスが実行される（すなわち、バイト、ショート、および整数はロングにキャストされ、文字列はポインタにキャストされる）。各属性のカタログ情報は、ｔｈｉｓａｔｔという名前の構造体に記憶される。リスト１が示すように、属性の長さ（ａｔｔｌｅｎ）、属性の物理的記憶整合（ａｔｔａｌｉｇｎ）、および属性のオフセット（ａｔｔｃａｃｈｅｏｆｆ）は全て、特定の実行パスを選択する際に関与する。
従来のＤＢＭＳ実装内部では、これらの変数の値はクエリされている特定の関係に依存するため、変数は分岐条件チェックで評価される。このような実装は、ＤＢＭＳの汎用性をサポートするために必要であるが、性能向上の機会を提供する。マイクロ特化は、このような変数に注目し、これらがクエリ評価ループ内部で定数である場合、対応するコードシーケンスを大幅に短縮することができる。
マイクロ特化の適用を示すための例として、ＴＰＣ−Ｈベンチマークのｏｒｄｅｒｓ関係が利用される。最初に、ｏｒｄｅｒｓ関係のｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ（）関数を特化するために、定数である変数が識別される。スキーマによると、この関係では、ヌル値は全く許可されない。したがって、１３〜１８行目のヌルチェック文は、不要である。代わりに、特化コードの開始でｉｓｎｕｌｌ配列全体にｆａｌｓｅを代入することができる。ｉｓｎｕｌｌ配列の各値は１バイトであるため、代入は、いくつかの型キャストに分解することができる。例えば、ｉｓｎｕｌｌ［０］からｉｓｎｕｌｌ［７］までの８つの代入は、以下の単一の非常に効率的な文に変換することができる。
（ｌｏｎｇ＊）ｉｓｎｕｌｌ＝０；
前述のように、リスト１の変数のうちのいくつかは、任意の特定の関係で定数である。ｏｒｄｅｒｓ関係の場合、ｎａｔｔｓ（属性の数）変数の値は９である。ループの展開は、ｆｏｒ文の条件チェックおよびループカウンタの増分命令を回避するために適用される。得られるプログラムは単に９つの代入文を有する。
ｖａｌｕｅｓ［０］＝．．．；
ｖａｌｕｅｓ［１］＝．．．；
…
ｖａｌｕｅｓ［８］＝．．．；
次に、型特有の属性抽出文に注目する。ｏｒｄｅｒｓ関係の最初の属性は、４バイトの整数である。したがって、条件文でａｔｔｌｅｎ変数を参照する必要性は全くない。代わりに、この文では、タプルから直接整数値が代入される。
ｖａｌｕｅｓ［０］＝＊（ｉｎｔ＊）（ｄａｔａ）；
データ変数は、物理的タプルが記憶されるバイト配列であることに注意されたい。第２の属性もまた整数であるため、同じ文がここでも適用される。第１の属性の長さが４バイトであることを受けて、第２の属性のオフセットとして、４がデータに加えられる。
ｖａｌｕｅｓ［ｌ］＝＊（ｉｎｔ＊）（ｄａｔａ＋４）；
得られたｏｒｄｅｒｓ関係の特化コードは、リスト２に示される。リスト１のｆｏｒループは、関連する関係の属性の数に応じて、何回も実行されることに注意されたい。その結果、特化コードは、元のコードよりもはるかに少ない命令を実行する。
実行可能オブジェクトコードの手動検証では、ｆｏｒループは、以下のクエリを実行する際にｏｒｄｅｒｓ関係で約３１９の機械命令（ｘ８６）を実行することが見出された。
ＳＥＬＥＣＴ ｏ＿ｓｈｉｐｐｒｉｏｒｉｔｙ ＦＲＯＭ ｏｒｄｅｒｓ；
特化コードを実行するために、リスト３に示されるように、ＧｅｔＣｏｌｕｍｎｓＴｏＬｏｎｇｓ（）関数への関数呼び出しがｆｏｒループを置換するために挿入される。リスト３では、６〜１１行目は、ＧＣＬｒｏｕｔｉｎｅへの呼び出しを表すことに注意されたい。１５行目から開始して、コードブロックは、リスト１に示される３〜４３行目によって囲まれたコードブロックと同一である。ＧＣＬルーチンは、上記のコードブロックに効果的に代わる。特化ＧＣＬルーチンは、６４回しか命令を実行せず、約２５５（３１９−６４）回の命令の削減となる。
実際に実現される性能メリットを判定するため、上記のクエリが詳細に研究された。このクエリは、１．５Ｍのタプルを有する、ｏｒｄｅｒｓ関係上のシーケンシャルスキャンを要求する（ＴＰＣ−Ｈデータセットでスケールファクタを１に設定した場合）。特化コードが２５５の命令を節約し、コードが１．５Ｍ回起動されるとすると（クエリ評価ループ内部のタプル１つにつき）、命令の合計数は、３８２Ｍ減少すると予想される。
実行プロファイルを収集するために、ＣＡＬＬＧＲＩＮＤ［３］が利用された。ＣＡＬＬＧＲＩＮＤによって生成された要約データは、実行された命令の合計数、各関数の命令数、他の実行時情報を記述する。まず、実行された命令のカウントに注目する。
このクエリの実行は、普通のＰｏｓｔｇｒｅＳＱＬおよびｆｏｒループを置換するより短いコードを含むものの両方でプロファイルされた。（第４項を参照）。これらの２つの実行の詳細のプロファイル要約は、リスト４およびリスト５にそれぞれ提供される。表記Ｉｒは、実行された命令の数を表すことに注意されたい。
予想どおり、普通のＰｏｓｔｇｒｅＳＱＬの命令の最高数（５４８Ｍ）（リスト４に示される）に寄与する、ｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ関数は、ｆｏｒループに代わるために特化されたＧｅｔＣｏｌｕｍｎｓＴｏＬｏｎｇｓルーチンが実行されると、はるかに少ない命令（８４Ｍ）を実行した。この特化されたルーチンは、リスト５に示されたそのアドレス（０ｘ０００００００００４３ｆ５３ｃ０）によって表され、９６Ｍの命令を必要とする。
具体的には、普通のＰｏｓｔｇｒｅＳＱＬの実行された命令の合計数は３．４４８Ｂであり、このマイクロ特化は、約１１％（３８２Ｍ／３．４４８Ｂ）の（推定）削減を生じることを暗示する。特化されたＰｏｓｔｇｒｅＳＱＬによって実際に実行された命令の合計数は、３．１０７Ｂであり、３４１Ｍの命令の（測定された）削減、または１０％で、我々の推定に一致する。クエリの合計実行時間は、普通のＰｏｓｔｇｒｅＳＱＬおよび特化バージョン上で測定され、それぞれ、６５２ミリ秒および５９２ミリ秒である。９％を超える実行時間の向上はプロファイル解析に一致する。
クエリ評価ループ内部の単一ルーチンを特化することによって、汎用のｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ（）関数は、わずかな変数だけに関して、３９行のコード（ＰｏｓｔｇｒｅＳＱＬの３８０，０００コード行のうち）を特化バージョンに置換し、単純なクエリ上で７．２％の実行時間の向上が達成された。この向上は、マイクロ特化を積極的に適用することの実現可能性および利点を示唆する。
各マイクロ特化は、その値がクエリ評価ループ内部で定数である、１つ以上の変数を識別する。これらの変数を参照する元のコードは、次いで、各々がそれらの変数の各々の単一の値に固有である、特化コードの複数のコピーによって置換される。上記の例において、変数は、スキャンされている特定の関係に関係した。したがって、ＧｅｔＣｏｌｕｍｎｓＴｏＬｏｎｇｓ（）の特化バージョンは、各関係に必要である。
マイクロ特化は、汎用コードを高度に特化されたコードと置換する。この動的なコード特化ベースの手法は、他の積極的な特化技法に緊密に関係する。例えば、Ｋｒｉｋｅｌｌａｓらは、クエリコンパイルベースの特化手法を研究した［８］。クエリのコンパイルは究極的に、クエリ評価コードを特定のクエリに特異的であるように特化するため、得られる特化コードは、高度に最適化され、このために、非常に効率的であり得る。このような手法は、マイクロ特化によって達成することが可能な性能利点に上限を提供する。Ｋｒｉｋｅｌｌａｓによって報告されるように、ＴＰＣ−Ｈベンチマークにおいてクエリ３に対して達成された実行時の高速化は、１０倍を上回った。マイクロ特化によって実現される一般的な性能の利点の研究は、第８項に提供される。現在の実装では、わずかなビー（ｂｅｅ）ルーチンだけで、マイクロ特化によってクエリ３では、１０％を超える性能向上（または１．１Ｘ高速化）が実現され、最も顕著な向上は、最高３８％（または１．６Ｘ高速化）である。多数のビールーチンの機会が存在するため、ビーがより完全に活用される場合、数倍の高速化に対する可能性が存在する。
第３項：手法
前項に例示されるように、あるマイクロ特化を適用する経験から、マイクロ特化は、ＤＢＭＳ内部のその広い適用可能性の分類によって汎用化される。さらに、いつ、多様な種類のマイクロ特化が適用可能か、および適用されるべきであるか、詳細理論が提供される。
３．１ 用語
以下の用語が導入される。
・特化コードは、コンパイルされ、リンクされた後、「ビー（ｂｅｅ）」と呼ばれる。これは、特化コードのサイズが小さく、実行中に効率的であるためである。可能性として、クエリを評価するために、特化コードの多数のインスタンスを採用することができる。特化コードは、ビーの特徴に類似する。事例研究で検討されるように、特定の関係に関連するビーは、「関係ビー」と呼ばれる。
・ビーは、複数の「ビールーチン」を有することができ、各々、クエリ評価ループ全体でローカルに不変量であると識別された１つ以上の変数に関してＤＢＭＳソースコードにおいて所定の場所で特定のマイクロ特化によって生成される。
・ビーのソースコードがコンパイルされると、「プロトビー」が生成される。プロトビーは、実際に実行可能なビーを形成するために、実行時の値で充填される、「穴」を含む場合があるので直接実行可能ではない。すなわち、プロトビーは、実際のビーのプロトタイプとして機能する。さらに、複数のバージョンのプロトビーが存在してもよく、各々、ビーによって実施されるタスクによって必要な個別のコード分岐を表す。
・ビーの構築、起動、リソース割当および再利用のサポートを含む、実行時のビーの管理は、「ハイブ（Ｈｉｖｅ）実行時環境」（ＨＲＥ）、によって自動的に処理され、ＤＢＭＳに依存しないＡＰＩ（モジュール）がＤＢＭＳに組み込まれ、マイクロ特化を可能にする。
事例研究において、マイクロ特化は、各関係で一定である値（属性の長さ等）に適用され、ビールーチンの結果も一定である。この特定のビールーチンは、特化されたＧｅｔＣｏｌｕｍｎｓＴｏＬｏｎｇｓ（）ルーチンの短縮形として、ＧＣＬと呼ばれる。データベースに定義されたあらゆる関係に固有の関係ビーが存在することになる。
ｈｅａｐ＿ｆｉｌｌ＿ｔｕｐｌｅという名前の、ロング整数配列から記憶されるタプルを構築する別のＰｏｓｔｇｒｅＳＱＬ関数が特化され、各関係に対してＳｅｔＣｏｌｕｍｎｓＦｒｏｍＬｏｎｇｓ（）（ＳＣＬ）という名前の追加のビールーチンになる。このため、各関係ビーは２つのビールーチンを有するようになる。
この一般的な手法では、どこでマイクロ特化を適用できるか、およびタイムライン中のいつ、クエリ評価に対する関係スキーマ定義からマイクロ特化を実行することができるか、という２つの重要な疑問が生じる。
３．２ どこでマイクロ特化を適用するか？
マイクロ特化に対する手法の分類１００は、記憶されたデータ１１２および内部データ構造１１４という、マイクロ特化を適用することができるＤＢＭＳの「変数」の２つの型に基づいて、図１に示される。分類１００はまた、アーキテクチャレベルの特化１０４、構成要素レベルの特化１０６、およびユーザ規定レベルの特化１０８を含む、他のもっと粗い粒度の特化も含む。
上記は、関係ビー１２０内部の２つのビールーチンである。これらの特化コードは、個別の関係の多様な特徴に基づき、したがって、特化は、関係スキーマ１１６の特化である。この特定の事例において、各属性の長さ、オフセット、整合、およびヌル可能な属性の存在、ならびに関係の属性の数に関して特化する。
マイクロ特化の適用は、タプルビー１２４を導入することによって、個別のタプルにまで拡張することができ、特化は、タプル内部の特定の属性の値に注目する。「性別」等、２、３の特有値１１８を持つ属性を検討する。値抽出ルーチンが属性の長さ、オフセット、整合を計算する代わりに、この属性の値を要求すると、ｖａｌｕｅｓ［ｘ］＝‘Ｍ’；等の単一の代入でこの属性の値抽出を正しく満たすことができる。これは、そのタプルに関連するタプルビー内部で発生し、これは、このようなタプルに、ビーＩＤ（ｂｅｅＩＤ）と呼ぶ、適切なタプルビーを識別する短いインデックスを含めることによって実行される。したがって、例えば、各性別に１つずつ、２つのタプルビーだけが存在する場合、または生成されるタプルビーが多すぎない限り、他の属性に関しても特化する場合があるので、関係内のタプル全てに対して少数のタプルビーが生成される。タプルビーの数量の選択は、特定の実装検討を含めて第４項に説明する。
最後の種類のビーは、クエリ評価中に発行された内部データ構造１１４に関して特化され、データ構造内の値のうちのいくつかは、クエリの評価ループ中に一定である。例えば、述語が関与するクエリは、述語をエンコードするためにＦｕｎｃＥｘｐｒＳｔａｔｅデータ構造体（ｓｔｒｕｃｔ）を利用する。述語「ａｇｅ＜＝４５」の場合、述語のデータ構造は、属性ａｇｅのＩＤ、＜＝演算子、および定数４５を含む。クエリの述語がわかると、これらの変数に特化を適用することができる。このようなクエリに関するデータ構造を特化することから得られるビーは、このために「クエリビー」１２８と呼ばれる。
さらに、この分類には、「ページビー」１２２、「修正ビー」１３０および「コンパイルビー」１２６の概念が組み入れられる。具体的には、ページビー１２２は、ページが完全または空である、およびページ内部のタプルの数等、特定のページ内部に記憶された情報を利用することができる。修正ビー１３０は、削除または更新を実施する特定の型のトランザクションに合わせてカスタム化することができる。最後に、ＰｏｓｔｇｒｅＳＱＬ等の従来のＤＢＭＳは、クエリ評価時に、ｓｗｉｔｃｈ−ｃａｓｅベースの非効率的な実装を回避するために、例えば、コンパイル前の型特定比較関数である、関数ポインタを利用することが認識される。これらのコンパイル前の型特定関数は、これらの関数がＤＢＭＳコンパイル時にコンパイルされるという事実を除いて、ビーに対する実質的な類似性を示す。したがって、これらは「コンパイルビー」１２６と呼ばれる。
この分類は、ビーを作成するために特化する変数の種類に応じて、６つの異なる種類のビーを特徴付ける。クエリ評価ループ内部で頻繁に実行されるコードによって使用される値を識別することによって、多くのビールーチンを作成することができる。各ビールーチンは、クエリおよび修正のサブセットを独立的に高速化する。
３．３ どのようにマイクロ特化を適用することができるか？
マイクロ特化は、ＤＢＭＳ内部の多数の場所に適用することができる。マイクロ特化は、これらの値が属する実際のＤＢＭＳ構成要素に特定ではなく、クエリ評価ループ内に存在する特定の値に適用されるという事実に起因して、マイクロ特化の適用における多様性は実質的な複雑性を生じない。
一般に、マイクロ特化の適用は、以下のシーケンスの５つのタスクを利用する。これらのタスクの簡単な説明をここに記載する。これらのタスクは後の項でさらに説明する。
・ビー設計は、クエリ評価ループおよびこのループ内部に存在する実行時不変量である変数を識別するために、動的および静的両方のプログラム解析に依存する。次いで、これらの識別された不変量の値に応じて、特化バージョンのソースコードが、通常、個別のコード分岐に対応するコードスニペットの形式で、作られる。
・ビーソースコード作成では、適切なコードスニペットを組み合わせることによって、ビーソースコードが作成される。
・プロトビー生成は、実行可能コードを形成するために、上記のタスクから生成されたソースコードをコンパイルし、プロトビーとなる。このステップでは、Ｃコンパイラが起動され、わずかとはいえないオーバーヘッドが生じるため、この特定のタスクがいつ実施されるかについて、注意しなければならないことに注意されたい。
・ビーインスタンス化によって、プロトビーに存在する所定の定数の値等、実行時情報で実行可能コードを更新する。ビーインスタンス化は究極的に、（動的）リンカーの役割を果たし、最終実行可能ビーを生成する。その値が実行時にのみ決定することができる、このような定数を全く含まない関係ビー等、いくつかのビーの場合、ビーインスタンス化ではプロトビーに対する修正は全く不要である。
・ビー起動は、実行時にＤＢＭＳによってインスタンス化されたビーが起動される。
ビーインスタンス化の１つの機構は、プロトビー上のオブジェクトコード操作である。プロトビーは、究極的にプレースホルダーを持つオブジェクトコードであり、各々がビーソースコード内にハードコードされたマジックナンバーとして表され、ソースコードをオブジェクトコードにコンパイルする際に容易に識別することができる。プレースホルダーの使用の一例は、関数アドレスである。ビーソースコードが設計される際、動的リンクを管理することを要求する関数呼び出しは、直接利用することができない。代わりに、ビー内部の各関数呼び出しは、動的関数アドレスとして表される。ビーのインスタンス化時、これらのマジックナンバーは、ビーによって起動される実際の関数アドレスに置換される。
３．４ いつマイクロ特化を適用できるか？
表３．１は、各種ビーに対して、ＤＢＭＳコンパイルからクエリ評価までのタイムライン上で、５つのタスクの各々が実施されなければならないタイミングを要約する。タイムラインは、ＤＢＭＳが設計、実装される時点である「ＤＢＭＳ開発」から開始する。「ＤＢＭＳコンパイル」は、ＤＢＭＳのソースコードが実行可能プログラムにコンパイルされる時点を表す。ＤＢＭＳ実行可能ファイルがユーザによってインストールされ、ＤＢＭＳサーバが起動すると、データベースを作成することができる。この時点は「データベース作成」と呼ばれる。作成されたデータベース内部で、指定されたデータ定義言語（ＤＤＬ）文にしたがって関係が作成され得る。この段階は「スキーマ定義」と呼ばれる。クエリがＤＢＭＳに提示されると、クエリ計画を演算するために、最初に「クエリ準備段階」が起動される。その後、実際のクエリ評価およびタプルアクセス／修正を実行することができる。それぞれの連続するタスクは、その前のタスクの完了後に発生しなければならないことに注意されたい。もう１つの重要な問題は、ビー生成がゆっくりであることで、コンパイラを起動することが必要である。このため、ビー生成は、可能であれば、クエリ評価中は回避すべきである。
前述のように、コンパイルビーの例は、ＰｏｓｔｇｒｅＳＱＬに実装されたコンパイル前の型特異比較関数である。これらの関数のソースコードは、ＤＢＭＳソースコードと共に実装される。これらの関数の実行可能コードの生成は、ＤＢＭＳがコンパイルされる際に実施される。生成されたコードのインスタンス化は、コンパイラおよびリンカーによって直接行われる。
事実、全ての種類のビーでは、設計はＤＢＭＳソースコードが開発されると同時に発生することが必要である。これは、ビーの設計は主にホストＤＢＭＳに存在するコード実行パスに依存するためである。実行時にビーがこれらの代替実行パスと同じ方式で実施されることを保証するためには、ビーのソースコードスニペットを作成するために既存のソースコードを直接利用することで十分である。
コンパイルビーは、クエリ評価時およびタプルアクセスまたは修正時の両方で起動することができる。
関係ビーの場合、そのソースコードスニペットは、属性型特異的である。属性の型（ＩＮＴ、ＣＨＡＲ、またはＮＵＭＥＲＩＣ）それぞれで、対応する属性値は、異なるコード分岐を含むタプルから抽出される。関係のスキーマが定義されると、属性型全てが明らかになる。したがって、特定の関係に対する関係ビーを形成するために、対応するコードスニペットを選択することができる。関係定義は実施に重要なタスクではないため、関係が定義された後、得られたビーのソースコードは、関係プロトビーを作成するためにコンパイルすることができる。さらに、各関係ビーは全体的にスキーマ定義および特定の関係の存在に依存するため、関係プロトビーは、次いで、スキーマ定義時にインスタンス化することができる。
タプルビーは、以下の第５項に詳細を説明するように、どちらも関係スキーマ特定であるため、関係ビーに非常に類似するので、タプルビーもソースコードの作成はスキーマ定義時に実施される。どちらにせよ、タプルビーの生成を実施するタイミングは、関係ビーより後である。スキーマ特定であることに加えて、タプルビーは、属性値特定でもある。その後、新しいタプルビーの生成は、修正中、具体的には、挿入および更新中にのみ実行することができる。タプルビーが生成された後、修正と共にインスタンス化される。
関係ビーおよびタプルビーの両方は、クエリ評価およびタプルアクセスまたは修正中に起動することができる。ビーは、インスタンス化された後にのみ起動することができ、インスタンス化によって、ビーの実行に必要な実行時情報を組み入れるようにビーのオブジェクトコードを修正することに注意されたい。表３．１には、タプルビーが、修正前に発生するクエリ評価中に起動されると示されるが、タプル挿入等、修正中にインスタンス化されていたタプルビーだけがクエリ評価中に起動することができる。
クエリビーのソースコードは、ＤＢＭＳコンパイル時点で作成され、クエリビーは究極的には、ＤＢＭＳとともに設計される、クエリ評価アルゴリズムの特化の（小さい）部分である。クエリビーの生成を実施するには、ＤＢＭＳコンパイル時点またはデータベース作成時点のいずれかという、２つの選択肢が存在する。本明細書に開示される実施形態の実装において、クエリビーはデータベース作成中に作成される。クエリ特定の情報は、クエリの計画が作成された時点のみ利用可能であるため、クエリビーのインスタンス化は、クエリ準備時点でのみ実行することができる。
クエリビーは、クエリ評価および修正中に起動することができる。
修正ビーの場合、挿入、更新、および削除操作はスキーマ依存であるため、修正ビーの作成は、スキーマ定義中に発生してもよい。修正ビーの生成は、スキーマ定義時にも予定することができる。実際の修正中、修正ビーは、適切な実行時値でインスタンス化することができる。
修正ビーは、修正中にのみ起動されなければならない。
最後に、ページビーの作成は、データベース作成時に発生すべきで、ページのサイズおよびページの種類（メモリ内およびディスク上）等の重要な情報は、通常、データベース作成中に構成される。ページビーは、スキーマ定義中にも作成することができ、スキーマ情報は、ページアクセスコードをさらに特化するために利用することができる。例えば、属性全てが固定長である場合、ページ内部の各タプルのオフセットは、ページヘッダーを読み出すことなく、ページビーによって効率的に計算することができる。ページビーは、データベース作成およびスキーマ定義中に生成することができる。ＤＢＭＳバッファプール内で機能するメモリ内ページの場合、データベース作成中に生成することができる。タプルが記憶されるディスク上のページの場合、スキーマ関連の情報は、対応するページビーを考慮することが必要である。したがって、ディスク上のページビーは、スキーマ定義時に生成されなければならない。ページが割り当てられ、クエリおよび修正とともに再請求されるため、ページビーのインスタンス化は、クエリ評価および修正中に予定されなければならない。
ページビーは、クエリ評価時およびタプルアクセスまたは修正時のどちらの間でも起動することができる。タプルビーに類似して、修正中にインスタンス化されていたページビーだけがクエリ評価時に起動することができる。
個別のビーを作成し、生成することによって、追加のコードが（特化コードおよびビーのソースコードを作成するコードを含む）ＤＢＭＳに追加されているように思えるかもしれない。事実、導入された特化コードは元のコードを置換する。したがって、ＤＢＭＳの実行可能ファイルのサイズは削減される。ビーのソースコード作成を実施するコードに関して、このようなコードは、同じ種類のビーの間で共有され、例えば、関係ビーの作成は全て同じ関数を利用する。その後、ビーのソースコード作成を実施するためには、少数の行のソースコードだけが必要である。実行時、事例研究に例示されるように、特化コードによって相当な数の命令を削減することができる。したがって、メモリ内のクエリ評価コードのフットプリントは、各追加のビーによって実際に削減され、命令キャッシュミスも削減する（しかし、ＨＲＥが増加すると、フットプリントは、固定量分がやや増加する）。マイクロ特化の性能利点のより総合的な研究は、第８項に提供される。
第４項：ＨＩＶＥ実行時環境をＤＢＭＳに組み入れる
本項では、ＤＢＭＳの代わりにビーを作成し、ビールーチンを実行することに関連する基底の管理タスクの多くを実施するＤＢＭＳ独立モジュールである、ハイブ（Ｈｉｖｅ）実行時環境（ＨＲＥ）が導入される。ＨＲＥは、ＤＢＭＳにＡＰＩを提供し、それによって、既存のＤＢＭＳへの必要な修正を抑制しながら、マイクロ特化がＤＢＭＳに適用されることを容易にする。
４．１ ＨＩＶＥ実行時環境のアーキテクチャ
図２は、ＨＲＥを実装するために修正されたＤＢＭＳシステム１５０の従来のアーキテクチャ［５］を示す。最初に、従来のＤＢＭＳアーキテクチャ構成要素を説明し、その後、修正を説明する。
システム１５０は、データストレージモジュール（例えば、ディスク）上に記憶され、オペレーティングシステムによってアクセスされてもよい、データベース１５２とシステムカタログ１５４とを含む。システム１５０は、データベース１５２またはカタログ１５４の一部として記憶されるＤＢＭＳ情報へのアクセスを制御するように構成される上位の記憶データ管理モジュール１５６も含んでもよい。システム１５０は、データベース管理者（ＤＢＡ）担当者１５８、クエリを形成する通常のユーザ１６０、プログラミング言語を使用してプログラム１６４を作成するアプリケーションプログラマー１６２、およびパラメトリックユーザ１６６のためのインタフェースを含む。ＤＢＡ担当者１５８は、データベース１５２を定義し、ＤＤＬ文１７０および他の特権命令コマンド１７２を使用して、その定義への変更を行うことによって調整してもよい。
ＤＤＬコンパイラ１７４は、ＤＤＬ文１７０に指定されたスキーマ定義を処理し、スキーマの記述をＤＢＭＳカタログ１５４に記憶する。
データベースからの情報を時々必要とする通常のユーザ１６０は、システム１５０と相互作用するために、インタラクティブクエリインタフェース１７６を利用してもよい。クエリは、それらを内部形式にコンパイルする、クエリコンパイラ１７８によってコンパイルされてもよい。この内部クエリは、クエリオプティマイザ１８０によって最適化されてもよい。クエリオプティマイザ１８０は、記憶されたデータに関するシステムカタログ１５４情報にアクセスしてもよく、クエリに必要な操作を実施する実行可能コードを生成し、実行時データベースプロセッサ１８２を呼び出す。
アプリケーションプログラマー１６２は、プリコンパイラ１８４へ送信される（例えば、Ｊａｖａ（登録商標）、Ｃ、またはＣ＋＋の）プログラム１６４を作成する。プリコンパイラ１８４は、ＤＭＬコマンドを抽出し、データベース１５２にアクセスするためにコンパイルされたトランザクション１８８にコンパイルするために、それらをＤＭＬコンパイラ１８６へ送信する。プログラム１６４の残りは、ホスト言語コンパイラ１９０へ送信される。ＤＭＬコマンドのオブジェクトコードおよびプログラムの残りはリンクされ、実行時データベースプロセッサ１８２によって実行されてもよい、コンパイルされたトランザクション１８８を形成する。
ＨＲＥの構成要素は、注釈ＤＤＬプロセッサ１９２と、ビーコード生成機能１９４と、注釈干渉モジュール１９６と、ビー再構築機能１９８と、ビーソースコードレポジトリ２００と、ビー作成機能２０２と、ビー収集機能２０４と、ビーキャッシュ２０６と、ビーキャッシュマネージャー２０８と、ビー配置オプティマイザ２１０とを備える。ＨＲＥは、大部分がＤＢＭＳから独立した様式で、ビーの構成、ビーの生成、ビーの起動機能を提供する。
ＨＲＥ ＡＰＩによって提供されたメソッドを起動するためにＤＢＭＳに追加されたコード、およびＤＢＭＳ内部の既存のコードに必要な他の変更は、注釈モジュール２１２、注釈ＤＤＬプロセッサ起動機能２１４、挿入／更新プロセッサ２１６、ビー起動機能２１８、ビーデータプロセッサ２２２、および注釈メタデータ２２４を含む。図１の分類におけるビー種類全てを完全にサポートするために、３つの既存のＤＢＭＳ構成要素（ＤＤＬコンパイラ１７４、実行時データベースプロセッサ１８２、および記憶データ管理機能１５６）、２つのレポジトリ（システムカタログ／データ辞書１５４および記憶データベース１５２）、およびスキーマ（ＤＤＬ文１７０）は、追加されたコードを含めて拡大されることが必要である。太線は、ＨＲＥの構成要素への呼び出しを表し、破線はスキーマ情報の記憶またはアクセスのいずれかを表す。
マイクロ特化を適用する、すなわち、いくつかの汎用ＤＢＭＳコードを特化ビールーチンの呼び出しと置換する開発者は、ｉ）どのビールーチンを設計するか、ｉｉ）どのように対応するソースコードを作成するか、ｉｉｉ）どのようにプロトビーを生成するか、ｉｖ）どのようにプロトビーをインスタンス化するか、およびｖ）どのようにビールーチンの実行を有効にするか、を決定しなければならない。関連のタスクは、以下の第９項に記載する。ビーに対応するために従来のＤＢＭＳのアーキテクチャに必要な変更は、「ビー構成グループ」２３０および「クエリ評価グループ」２３２という２つのグループにそれぞれ対応して分類することができる。各グループ内部の構成要素をここで検討する。
４．１．１ ビー構成グループ
ビー構成グループ２３０は、ビーのソースコード作成およびプロトビーの生成を実施する。開発者は、多様なコード分岐に対応するソースコードスニペットを設計し、ビー構成グループは実行時に、適当なスニペットを合わせることによって、ビールーチンのソースコードを作成する。スニペットの選択は、マイクロ特化が適用される不変量の特定の値に合わせてカスタマイズされる。タプルビーおよびクエリビーの作成および生成の詳細、特に、このグループ内の構成要素がこれら２つのタスクにどのように関与するかについては、それぞれ、第５項および第６項に記載する。
４．１．２ クエリ評価グループ
クエリ評価グループ２３２は、ビーが、ＤＢＭＳ自体内部の動作によって正しく管理され、連結されることを保証するためのタスクを実施する８つの構成要素の集合体である。
まず、特定のビーのソースコードが作成された後、ビー作成機能が起動されて２つのタスクを実施する。まず、プロトビーは、ビーソースコードをコンパイルすることによって、生成される。次に、プロトビーは、存在する場合、プロトビーのプレースホルダーを置換する、正しい実行時値でインスタンス化される。このオブジェクトコードインスタンス化タスクによって、実際に実行可能なビーが生成される。ビー作成機能は、ビーのためのソースコードをコンパイルするためにＧＣＣに依存する。得られるオブジェクトファイル、例えば、実行可能およびリンク可能フォーマット（ＥＬＦ）［６］は、ヘッダー、テーブル、変数、および関数本体を含む情報の集合体を含み、これらは全て、その従来の使用において、ＥＬＦファイルがリンクされ、実行のためにメモリにロードされる際に有用である。しかし、ビーを組み立てるためには、ビールーチンに対応する関数本体だけが必要である。このため、ビー作成機能は関数本体を抽出し、それらを使用して、個別のビーを作成する。
ビーキャッシュマネージャーコンポーネントは、ビーがメインメモリにある間、ビーを管理する。ビーソースコードがオブジェクトコードにコンパイルされると、ビーが形成され、ビーキャッシュマネージャーによって管理される専用の実行可能メモリ領域に記憶される。メモリ内ビー記憶領域は、ディスク上に記憶されることが必要である。このディスク上のビーの記憶領域は、「ビーキャッシュ」と呼ばれる。データベース接続が終了されると、この接続から作成されたビーが、ビーキャッシュマネージャーによってディスクファイルにプッシュされるという簡単なポリシーが実装される。現在、ビーキャッシュは、電源喪失またはディスククラッシュ時に存続することが保証されていないが、安定したビーキャッシュは、ログに関連する元に戻す／再度実行ロジックを通じて実現することができる。ＤＢＭＳサーバが起動すると、ビー全て（またはおそらく必要なビーのみ）が実行可能メモリ領域にロードされるので、ビーが直接起動することができる。
クエリが評価されると、ビー呼び出し元は、適切な引数を取得する。例として、ＧＣＬルーチンはタプルへのポインタを必要とする（リスト２に示されるデータ引数）。ビー呼び出し元は、必要な引数をビーキャッシュマネージャーに渡し、ビーキャッシュマネージャーは、これらの引数で正しいビールーチンを起動する。ビーは、ビーを実行することによって生じる命令キャッシュミスが抑制されるように、ビー配置オプティマイザ２１０によって、メモリ内の専用場所に配置される。このようなメモリ場所をどのように選択するかの詳細検討は第７項に記載する。
最後に、ビー収集機能が、ビーキャッシュマネージャー（メインメモリ内のビー）およびディスク上のビーキャッシュ両方から、終了したビー（例えば、関係削除に起因して使用されることがないビー）をガーベッジコレクションする。
要約すると、図２に示される構成要素は、完全に詳細なＨＲＥを提供する。ＨＲＥは、６０００行のソースコード行（ＳＬＯＣ）からなる。上述のように、ＨＲＥは、既存のＤＢＭＳに最小限の変更を招く。我々の実装において、ＰｏｓｔｇｒｅＳＱＬへの変更は、図２の濃い影のボックスによって表されるように、約６００ＳＬＯＣである。この変更は、ビーを有効にするためにのみ必要である、引数準備、メモリ割り当て、リソースリクラメーション、およびビー起動の文を含む。ＤＢＭＳに行われた変更は、３８０ＫのＳＬＯＣのＰｏｓｔｇｒｅＳＱＬ ＤＢＭＳに比較すると、最小限である。
一般に、このマイクロ特化手法の利点は、ビーがＤＢＭＳ外部で生成され、オンザフライで起動され、したがって、既存のＤＢＭＳに対する変更は、ＨＲＥがＤＢＭＳに独立的であることを効果的に可能にし、このために大規模なリファクタリングを行うことなく他のＤＢＭＳで採用可能である、関数ポインタの割り当て、パラメータの初期化、およびリソースのリクラメーション等、最小限の組のサポート文だけを含むことである。
４．２ 技術的検討事項
ここでは、ＨＲＥの設計および実装中に存在する３つの技術的課題、およびこれらの課題のために採用される解決策を中心とする。
４．２．１ タプルビー内のコード共有を可能にする
第４．１．２項で導入されたように、ビーキャッシュは、ビーが配置されるディスク上の記憶領域である。具体的には、ビーキャッシュは、ビールーチンセクションおよびデータセクションという、２つのセクションからなる。技術的には、各ビーは、専用ルーチンセクションおよびデータセクションからなる。ルーチンセクション内のルーチンは、実行時にデータセクションにアクセスする。このような構成の欠点として、特に新しいビーおよび新しいビールーチンが追加されると、ビー全ての全体として必要となる記憶領域が急速に増大する可能性がある。同じ関係のタプルビーの全てが実際に同じ機能を共有し、タプルから値を抽出し、生の値からタプルを構築するという点から、したがって、これらのタプルビーは、同じ組のビールーチンを効果的に利用することができる。その後、特定の関係の同じプロトビーバージョンからインスタンス化されるタプルビー全てに対して、グローバルルーチンセクションがビーキャッシュに構築される。
タプルビールーチンコードを共有する利点は、ディスク上およびメモリ内にタプルビーを記憶するために必要な記憶領域を抑制することである。具体的には、コード共有戦略は、レベル２キャッシュに対する負担を効果的に抑制し、実験マシン上では２５６ＫＢである。加えて、レベル１の命令キャッシュ性能もまた、多数の異なるタプルビーが起動されるにもかかわらず向上し、特定のビールーチンに属する同じ組の命令は、各タプルビーが個別のルーチンセクションを要求する場合、除去されることなく、命令キャッシュに残される。
４．２．２ 動的に生成されたコードを実行する
ビーソースコードはＧＣＣを使用してコンパイルされる。この結果、多様なヘッダーおよびコードセクション［６］を含むオブジェクトファイルが得られる。これらの構成要素は、オブジェクトファイルがその従来の使用で実行またはリンクされる際の重要な情報を含む。これらの構成要素の中でも、実際の実行可能なマシンコードを記憶する、．ｔｅｘｔセクションがビーに変換される。技術的懸念は、．ｒｅｌａ．ｔｅｘｔ［６］セクションも存在する際に発生する。この特定のセクションは、オブジェクトコード再配置を実施するためのリンカーのデータを含む。具体的には、ソースコードがハードコードされた文字列またはｓｗｉｔｃｈ−ｃａｓｅ文を含む場合、．ｒｅｌａ．ｔｅｘｔセクションが生成される。．ｒｅｌａ．ｔｅｘｔセクションをビー起動および実行機構に組み入れると、実行時のオーバーヘッドおよび技術的複雑性が導入される。ビーを小さいままに保ち（ビーコード内のこの追加のコードセクションを避けることによって）、かつビーコードに高度なリンカーを実装することを避けるために、ビーソースコードが、コンパイル後に．ｒｅｌａ．ｔｅｘｔセクションに変換されるコンストラクトを含まないことを保証することによって、再配置演算が迂回される。この目標を達成するために、ビーソースコードを作成する際に以下の２つの規則に依存した。
・ソースコード内に文字列を直接ハードコードする代わりに、データセクションに文字列を個別に記憶する。実行時に正しいデータセクションにアクセスするために、特定のデータセクションのオフセットを計算するために、ビーＩＤを採用する。したがって、ソースコード内では、データセクションに記憶された文字列は、メモリアドレスを参照することによって直接アクセスされる。
・ｓｗｉｔｃｈ−ｃａｓｅ文を避けるために、同等な代替として、ｉｆ−ｅｌｓｅ文を使用する。
実行時に、究極的には実行可能コードであるビーは、メインメモリにロードして実行する。このビーロード操作は、ＯＳ ＡＰＩ機能の集合体によって実行される。具体的には、メインメモリの実行可能領域は最初に割り当てることが必要である。これは、ｐｏｓｉｘ＿ｍｅｍａｌｉｇｎ（）関数によって実行される。ビーがこの割り当てられたメモリ内にロードされ、内部で実行されることを可能にするため、このメモリ領域に読み取り可能、書き込み可能、実行可能フラグを設定するために関数ｍｐｒｏｔｅｃｔ（）が呼び出される必要がある。関数は、以下の表現規則で呼び出される。
ｍｐｒｏｔｅｃｔ（ｍｅｍｏｒｙ＿ａｄｄｒｅｓｓ，ｍｅｍｏｒｙ＿ｓｉｚｅ，ＰＲＯＴ＿ＲＥＡＤ｜ＰＲＯＴ＿ＷＲＩＴＥ｜ＰＲＯＴ＿ＥＸＥＣ）；
ビーがこの割り当てられたメモリ領域内にロードされると、メモリブロック全体は、以下の関数呼び出しによって再度保護されるはずである。
ｍｐｒｏｔｅｃｔ（ｍｅｍｏｒｙ＿ａｄｄｒｅｓｓ，ｍｅｍｏｒｙ＿ｓｉｚｅ，ＰＲＯＴ＿ＲＥＡＤ｜ＰＲＯＴ＿ＥＸＥＣ）；
ＰＲＯＴ ＷＲＩＴＥフラグを排除することによって、このメモリブロックに記憶された内容はもはや変更することができない。ＤＢＭＳサーバが終了すると、割り当てられたメモリページ全ては解放される。
４．２．３．ビー配置
第４．１．２項で導入したように、ビーは、命令キャッシュミスを削減するために、「ビー配置オプティマイザ」２１０によってメインメモリに配置される。各ビーに対して、ビーを配置し、記憶するために、３ページのメインメモリページ（各々４ＫＢ）が必要である。これは、実験マシンにおいて、ＣＰＵ上の各コアは、各キャッシュ行が６４バイトの幅を備え、３２ＫＢ４方式設定関連レベル１命令キャッシュで構成されるためである。この命令キャッシュは、２ページのメモリページに相当する、合計で８ＫＢのメインメモリ空間にマッピングされる。すなわち、８ＫＢのメインメモリは、１２８の固有のキャッシュスロット全てを網羅する。例えば、第１のキャッシュスロットが、割り当てられた８ＫＢのメモリの最初の６４バイトにマッピングされ、１２８番目のキャッシュスロットは、この割り当てられたメモリ領域の最後の６４バイトにマッピングされる。したがって、最後のキャッシュ行の６４バイトを超える場合がある、ビー全体がメモリ内に正しく記憶できるように、追加のメモリページが必要となる。
４．３ ＨＩＶＥ実行時環境ＡＰＩ
ＡＰＩは、ＨＲＥがＤＢＭＳに組み込まれることを可能にするように設計された。このＡＰＩは、ＨＲＥが多数のＤＢＭＳによって使用できるように、ＤＢＭＳ独立であるように設計される。このＡＰＩの詳細は、図３に示されるＡＰＩの静的コールグラフ２５０で図示される。
図３において、左側に挙げられた８つの関数２５２は、ＤＢＭＳ２５８によって直接起動される。これらの８つの関数２５２は、連携してＡＰＩを形成する。右側に挙げられた１０の関数２５４は、ＨＲＥ内部で内部的に起動される補助関数である。ＤＢＭＳ２５８は、これらの１０の関数２５４を直接起動しない。このＡＰＩに存在する８つの関数２５２の各々の総合的な説明をここに記載する。
４．３．１ ＨＲＥ ＡＰＩでマイクロ特化を適用する
マイクロ特化を適用するために必要な５つのシーケンシャルタスクは、第３．３項で既に検討した。これらは、リスト３に例示したように、各ビーに対しての、（ａ）設計、（ｂ）作成、（ｃ）プロトビーを生成、（ｄ）インスタンス化、そしてその後（ｅ）起動である。ＡＰＩ機能の検討をここで、これらのタスクを実施する状況で要約する。図４は、各ＡＰＩ関数が起動されるタイミングを図示するフローチャート２９０を表す。
ＤＢＭＳ２５８がコンパイルされる前に、ビー全てが設計される。このタスクには、ＡＰＩ関数は全く不要である。クエリビーの場合、ソースコードは、ＤＢＭＳ開発中に、ＤＢＭＳソースコードとともに作成される。クエリプロトビーの生成は、ＤＢＭＳコンパイル中に実施される。
ＤＢＭＳ２５８は、ＩｎｉｔＱｕｅｒｙＢｅｅｓ２７０およびＩｎｉｔＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓ２７２関数を呼び出すことによって、ＨＲＥとの相互作用を初期化する。
ＣｒｅａｔｅＡｎｄＧｅｎｅｒａｔｅＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓ２７８関数は、新しい関係が定義されると、ＤＢＭＳ５８によって起動される。この関数２７８は、関係およびタプルビーのためにビーソースコードの作成およびプロトビー生成タスクを実施する。上述のように、ＨＲＥ ＡＰＩは、クエリビーのソースコードを作成するための関数を一切提供する必要はない。
関係がドロップされると、ＤＢＭＳ２５８によってＧａｒｂａｇｅＣｏｌｌｅｃｔＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓ２８４関数が起動される。
クエリ準備時に、ＤＢＭＳ２５８は、クエリビーのインスタンス化タスクを実施する、ＩｎｓｔａｎｔｉａｔｅＱｕｅｒｙＢｅｅ２８２関数を起動する。関係およびタプルビーのインスタンス化は、ＩｎｓｔａｎｔｉａｔｅＲｅｌａｔｉｏｎＯｒＴｕｐｌｅＢｅｅ２８０関数によって実施され、関係およびタプルビーが生成された後に実行される。
ビーのインスタンス化後、ＤＢＭＳ２５８によってＰｌａｃｅＢｅｅｓ２７６関数が起動される。第２項に詳細を記載したように、ビー起動は、ＤＢＭＳ２５８に挿入された関数呼び出しによって実施されるため、ビーを起動するためにＨＲＥ−ＡＰＩ関数は全く利用されない。
最後に、ＤＢＭＳサーバが終了する際、割り当てられたリソースを解放するために、ＦｒｅｅＡｌｌＢｅｅｓ２７４関数が呼び出される。
４．３．２ データ構造定義
ｓｔｒｕｃｔ ＲｅｌａｔｉｏｎＤｅｆｉｎｉｔｉｏｎ｛
ｉｎｔ ｄａｔａｂａｓｅ＿ｉｄ；
ｉｎｔ ｒｅｌａｔｉｏｎ＿ｉｄ；
ｉｎｔ ｎｕｍ＿ａｔｔｒｉｂｕｔｅｓ；
ｂｏｏｌ ｎｏ＿ｎｕｌｌａｂｌｅ＿ａｔｔｒｉｂｕｔｅ；
ＡｔｔｒｉｂｕｔｅＤｅｆｉｎｉｔｉｏｎ＊ａｔｔｒｉｂｕｔｅｓ；
｝
関係およびタプルビーの作成は、関係スキーマに依存する。異なるＤＢＭＳは、多様な方式でスキーマを内部管理する一方、関係およびタプルビーの作成に必要な情報が抽出され、ＨＲＥによって利用されるＲｅｌａｔｉｏｎＤｅｆｉｎｉｔｉｏｎデータ構造体が設計された。ｄａｔａｂａｓｅ＿ｉｄおよびｒｅｌａｔｉｏｎ＿ｉｄのフィールドは、それぞれ、ＤＢＭＳによってデータベースおよびこの関係を一意に識別する。これらの２つの変数は、ＨＲＥ ＡＰＩへの起動の際の関与とともに後述する。ＲｅｌａｔｉｏｎＤｅｆｉｎｉｔｉｏｎ構造体内のこれらの２つのフィールドは、ＤＢＭＳによって管理されるデータベースカタログを照合するためにＨＲＥによって使用されるので、ＨＲＥは、関係およびデータベースの追加のＩＤを必要としない。
ｎｕｍ＿ａｔｔｒｉｂｕｔｅｓは、現在の関係内の属性の数を指定する。ｎｏ＿ｎｕｌｌａｂｌｅ＿ａｔｔｒｉｂｕｔｅフラグは、現在の関係がヌル可能な属性（複数可）を許可するかどうかを示す。このフラグは、関係およびタプルビー作成中に利用される。第２項に記載するように、関係がヌル可能な属性を許可しない場合、ヌル値をチェックするコードを排除することができる。
最後に、ＨＲＥは、関係およびタプルビーの作成に必要な属性特異的情報を記憶するために、ＡｔｔｒｉｂｕｔｅＤｅｆｉｎｉｔｉｏｎ構造体を定義する。
ｓｔｒｕｃｔ ＡｔｔｒｉｂｕｔｅＤｅｆｉｎｉｔｉｏｎ｛
ｉｎｔ ａｔｔｒｉｂｕｔｅ＿ｎｕｍ；
ｉｎｔ ａｔｔｒｉｂｕｔｅ＿ｔｙｐｅ；
ｉｎｔ ａｔｔｒｉｂｕｔｅ＿ｍａｘｌｅｎｇｔｈ；
ｉｎｔ ｄｏｍａｉｎ＿ｃａｒｄｉｎａｌｉｔｙ；
ｂｏｏｌ ａｔｔｒｉｂｕｔｅ＿ｓｐｅｃｉａｌｉｚｅｄ；
｝
ＡｔｔｒｉｂｕｔｅＤｅｆｉｎｉｔｉｏｎ構造体内で、ａｔｔｒｉｂｕｔｅ＿ｎｕｍフィールドは、各属性に対しゼロベースのインデックスである。ａｔｔｒｉｂｕｔｅ＿ｔｙｐｅフィールドは、整数で現在の属性の型を記述し、ＨＲＥによって内部でサポートされる。ＤＢＭＳ開発者は、この整数フィールドと各ＤＢＭＳによってサポートされる属性定義との間にＤＢＭＳに依存するマッピングを提供することが必要であることに注意されたい。例えば、属性型ロングは、ＰｏｓｔｇｒｅＳＱＬでは２０と表される。ＨＲＥでは、ロング属性型は値５によって示される。
ａｔｔｒｉｂｕｔｅ＿ｍａｘｌｅｎｇｔｈフィールドは属性の長さを指定する。可変長の属性の場合、これは、ＤＤＬに指定された最大長であることに注意されたい。例えば、ＶＡＲＣＨＡＲ（１２８）に従うと、ａｔｔｒｉｂｕｔｅ＿ｍａｘｌｅｎｇｔｈは１２８である。属性の最大長をキャプチャすることは特にタプルビー作成で重要である。第５項で詳細に検討する、ビーＩＤに基づいて計算されたオフセットによってデータセクションのアクセスを有効にするために、関係に関連するデータセクションは全て同じ長さを有することが求められる。各属性に対して指定された最大に許可される長さによって、データセクションが同じ長さであることを保証する。
ｄｏｍａｉｎ＿ｃａｒｄｉｎａｌｉｔｙフィールドは属性の個別の値の数を記憶する。ｄｏｍａｉｎ＿ｃａｒｄｉｎａｌｉｔｙは、特化される属性を決定するために、タプルビー作成中に利用される。特化属性は、ａｔｔｒｉｂｕｔｅ＿ｓｐｅｃｉａｌｉｚｅｄフラグをＴＲＵＥに設定することによって示される。特化されていない属性の場合、デフォルトで０の値がｄｏｍａｉｎ＿ｃａｒｄｉｎａｌｉｔｙフィールドに割り当てられる。
４．３．３ ｂｅｅｃａｃｈｅｍａｎａｇｅｒ．ｃ
ｂｅｅｃａｃｈｅｍａｎａｇｅｒ．ｃ構成要素２５６（図３を参照）は、ビーキャッシュ管理を提供する。ホストＤＢＭＳには４つの関数が有効である。
ｉｎｔ ＩｎｉｔＱｕｅｒｙＢｅｅｓ（）
この関数は、クエリビーをメモリにロードする。この関数は、ＤＢＭＳサーバプロセス開始中に、ＤＢＭＳによって起動される。この関数は、成功時０または、エラーが発生すると戻りコードを返す。戻りコードおよび原因は、表４．１に説明する。これらのＡＰＩ関数は全て重要なタスクを実施するため、これらの関数の実行中に発生するどのエラーでも、ＤＢＭＳサーバプロセスは終了されるべきである。
ｉｎｔ ＩｎｉｔＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓ（ｉｎｔ ｄａｔａｂａｓｅ＿ｉｄ）
この関数は、ｄａｔａｂａｓｅ＿ｉｄパラメータによって示されたデータベースに属する関係およびタプルビーだけをディスクからメモリにロードする。この関数は、ＤＢＭＳサーバメインプロセスによって、ならびにＰｏｓｔｇｒｅＳＱＬによって提供されるＡＮＡＬＹＺＥ設備等、関係の統計を計算するＤＢＭＳバックエンドプロセスによって直接起動することができる。このような設備は、短時間バックエンドで実行され、特定の関係に関してのみ操作される。その後、このようなプロセスのためにＨＲＥ全体を初期化する代わりに、関連の関係ビーおよびタプルビーだけが必要である。
この関数は、成功時０または、エラーが発生すると戻りコードを返す。表４．２にエラーコードおよび原因を記載する。
この関数は、ビーキャッシュによって割り当てられたメモリ領域を全て解放する。ＦｒｅｅＡｌｌＢｅｅｓは、データベース毎のサーバプロセスシャットダウン中にＤＢＭＳによって起動される。
ｉｎｔ ＰｌａｃｅＢｅｅｓ（）
この関数は、ビー配置オプティマイザ２１０（図３のｂｅｅｐｌａｃｅｍｅｎｔｏｐｔｉｍｉｚｅｒ．ｃ関数２６４も参照）によって実行された最適化に応じてビー配置を実施する。ＰｌａｃｅＢｅｅｓは、関係が定義された後、またはクエリ計画が特定のクエリに対してＤＢＭＳによって生成された後に起動され、その時点で、クエリに関連するビー全てがインスタンス化される。
この関数は、成功時０または、エラーが発生すると戻りコードを返す。表４．３にＰｌａｃｅＢｅｅｓ関数に関連する戻りコードおよび原因を要約する。
４．３．４ ｂｅｅｍａｋｅｒ．ｃ
この関数は、「ＣＲＥＡＴＥ ＴＡＢＬＥ ＤＤＬ」文の実行中に起動される。ＣｒｅａｔｅＡｎｄＧｅｎｅｒａｔｅＲｅｌａｔｉｏｎＡｎｄＢｅｅは、対応する関係およびタプルビーソースコードを作成するために、指定された関係スキーマを使用する。この関数は、生成されたソースコードをコンパイルするためにコンパイラを起動する。
この関数は、前述した関係定義という１つの入力パラメータをとる。ＤＢＭＳコードは最初に、ＤＢＭＳ属性型に対して、上記のマッピングを使用して、関係スキーマに含まれた情報からこのデータ構造を初期化しなければならない。
この関数は、属性の型に基づいて、コードスニペットを合わせて、関係またはタプルプロトビーにステッチングされる。複雑な事例では、このコード構築機構は、ソースコード翻訳という形で、ＤＢＭＳ開発者によって提供されることが必要な場合がある。潜在的に、実行時にソースコード作成が必要なビーは複数種類存在するかもしれない。対応するビーコード作成関数は、各種のビーに対して実装されることが必要である。これらの実装された関数は、ＨＲＥが作成されているビーの種類に応じて適切な関数を起動できるように、関数ポインタとして体系化されなければならない。
この関数は、成功時０または、エラーが発生すると戻りコードを返す。表４．４にＣｒｅａｔｅＡｎｄＧｅｎｅｒａｔｅＲｅｌａｔｉｏｎＡｎｄＢｅｅ関数に関連する戻りコードおよび原因を挙げる。
この関数は、関係からのｒｅｌａｔｉｏｎ＿ｉｄへのマッピングを安定した記憶に保持することも必要である。
この関数は、スキーマ定義時に関係ビーが生成された後、または修正中にタプルビーが生成された後に起動される。最初のパラメータｒｅｌａｔｉｏｎ＿ｉｄは、インスタンス化された関係またはタプルビーが関連付けられている関係を示す。リスト３に示されるように、ｒｅｌａｔｉｏｎ＿ｉｄは、特定のビーを起動するためにも利用される。次のパラメータ、ｐｌａｃｅｈｏｌｄｅｒ＿ｌｉｓｔは、第３．３項で説明されるように、ビーコードのプレースホルダーを置換するために挿入される値のリストを表す。この情報は、この呼び出しを追加するためにＤＢＭＳソースコードが修正される時点で明らかになる。
この関数は、成功時０または、エラーが発生すると戻りコードを返す。表４．５にＩｎｓｔａｎｔｉａｔｅＲｅｌａｔｉｏｎＯｒＴｕｐｌｅＢｅｅ関数に関連する戻りコードおよび原因を示す。
この関数は、各計画ノードの初期化タスクを実施する関数によって起動される。
関数は、関与する計画ノードに関連するビーをインスタンス化する。ＩｎｓｔａｎｔｉａｔｅＱｕｅｒｙＢｅｅは、入力として４つのパラメータを受け取る。最初のパラメータは、特定のクエリ計画ノードに対応するプロトビーのＩＤである。これらのＩＤは、クエリプロトビーが生成されると割り当てられる。次のパラメータは、インスタンス化されたビーのプレースホルダーを置換するために挿入される値のリストを表す。ｃａｌｌ＿ａｄｄｒｅｓｓｅｓパラメータは、この現在のビー内部から起動されるビーのアドレスを提供する。このアドレスの配列は、ＤＢＭＳがコンパイルされた後にのみ知られる、標準Ｃライブラリ関数等、補助関数も含むので、したがって、インスタンス化されたクエリビーは、実行時にビーコードおよびライブラリコードをリンクするために、リンカーを起動することなく、これらの関数を直接起動することができる。（第６．４項のクエリビーの起動についての説明を参照すること）コスト概算パラメータは、ビーがインスタンス化される計画ノードのコストモデル概算の値を表す。具体的には、この値が大きければ大きいほど、この計画ノードに関連するＤＢＭＳ関数が実行される頻度が高くなる。このパラメータは、ＤＢＭＳコードの実行時実行頻度を提供するので、インスタンス化されたビーの最適なキャッシュ配置を判定するために、ビー配置オプティマイザによって利用される。
この関数は、成功時０または、エラーが発生すると戻りコードを返す。表４．６にＩｎｓｔａｎｔｉａｔｅＱｕｅｒｙＢｅｅ関数に関連する戻りコードおよび原因を示す。
４．３．５ ｂｅｅｃｏｌｌｅｃｔｏｒ．ｃ
ｉｎｔ ＧａｒｂａｇｅＣｏｌｌｅｃｔＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓ（ｉｎｔ ｒｅｌａｔｉｏｎ＿ｉｄ）
ｂｅｅｃｏｌｌｅｃｔｏｒ．ｃ関数２６２（図３を参照）は、関係が削除されたためにもはや必要とされない関係およびタプルビーのガーベッジ収集を実施する。具体的には、影響のある関係ビーは、メモリ内およびディスク上両方のビーキャッシュから削除される。ＧａｒｂａｇｅＣｏｌｌｅｃｔＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓ関数に対する呼び出しは、「ＤＲＯＰ ＴＡＢＬＥ ＤＤＬ」文によってトリガされる。
この関数はパラメータとして、ドロップされた関係を識別する、ｒｅｌａｔｉｏｎ＿ｉｄを受け取る。ＧａｒｂａｇｅＣｏｌｌｅｃｔＲｅｌａｔｉｏｎＡｎｄＴｕｐｌｅＢｅｅｓは成功時に０、エラーが発生すると戻りコードを返す。表４．７にこの関数に関連する戻りコードおよび原因を示す。
第５項：関係およびタプルビー詳細
前項で導入されたように、関係ビーおよびタプルビーは、それぞれ、関係内部に記憶された特定のスキーマおよび値に関連する。さらに、ＰｏｓｔｇｒｅＳＱＬの属性値抽出関数に基づいて特化される、ＧＣＬという名前の関係／タプルビールーチンが検証された。ここでは、関係およびタプルビーがクエリ評価中にどのように設計され、利用されるかについて検討することとする。関係およびタプルビーがクエリ評価中に所定の共通性を共有する（簡潔に説明）が、タプルビーはより興味深い設計洞察を提供することから、タプルビーに絞って検討する。
５．１ 関係およびタプルビーによるクエリの実行
図５には、以下の単純なクエリを評価する際のタプルビーの特化役割に関する理解を提供するための例が示される。
ＳＥＬＥＣＴ＊ＦＲＯＭ ｏｒｄｅｒｓ；
図５は、元の関係スキーマ３００からの変換、およびタプルビーが存在する対応する特化スキーマ３０２を表す。この変換は、「元のスキーマ」３００から「特化スキーマ」３０２への矢印によって示される。「ビーキャッシュ」２０６（図２を参照）は、実行時のメモリ内の記憶空間を表し、この関係に関連するタプルビー全てが特定される。指定されたクエリが評価される際、ビーキャッシュ２０６内のタプルビーが起動される。「戻されたタプル」３１０として示される、特定のタプルを戻すために、対応するタプルビーは、（特化スキーマ３０２に従って）関係から関連属性値をフェッチし、これらの値およびタプルビー内部に記憶された特化値で戻されたタプル３１０を構築する。
図５において、「元のスキーマ」３００は、ＴＰＣ−Ｈベンチマークの順序関係からである。このスキーマ３００の３つの属性、ｏ＿ｏｒｄｅｒｓｔａｔｕｓ３０４、ｏ＿ｏｒｄｅｒｐｒｉｏｒｉｔｙ３０６、およびｏ＿ｓｈｉｐｐｒｉｏｒｉｔｙ３０８は、制限された離散値ドメインを有する。これらの値は、したがって特化され、タプルビー内部に記憶される。特化する属性（複数可）をどのように選択するかについては、第５．３項に詳細を記載する。特化後、「特化スキーマ」３０２によって示されるように、関係にはもはやこれらの属性が含まれない。代わりに、これらの属性の値は、「ビーキャッシュ」２０６内部の「データセクション」に記憶される。概念的には、各ビーは、ルーチンセクション３０７およびデータセクション３０９からなる。この例では、順序関係のタプルビーおよび関係ビーは、同じ組のビールーチン、すなわち第３項の事例研究で検討された、ＧＣＬおよびＳＣＬルーチンを共有することに注意されたい。したがって、実行時、タプルビーだけが起動される。一方、関係が特化属性を一切含まない場合、タプルビーに記憶されるタプル特異データは存在せず、この特定の関係の関係およびタプルビーは１つで同じである。
この例において、ルーチンセクション３０７は、順序関係のタプルビー全てによって共有され（第４．２．１項の関連技術詳細を参照）、各データセクション３０９は、ビーＩＤを介して参照される。ビーＩＤは、タプルヘッダーに記憶される仮想属性である（「記憶されたデータ」の破線ボックスによって示される）。ビーＩＤは、１バイトの長さであり、したがって、追加の記憶空間が不要であるように、タプルヘッダーに隠れるように注意深く設計され得る。ビーＩＤは１バイトであるために、タプルビーの最大許可数を２５６に制限する。各関係は、最大２５６までの個別のタプルビーを可能にすることに注意されたい。２５６は、ＴＰＣ−Ｈベンチマークの関係全てに対して十分な数であることが見出された。少数のビーは、ビーを記憶するための全体的に必要とされる記憶領域を削減する。
上記のクエリが評価される場合、「記憶されたタプル」を特定するために、関係スキャン操作が最初に実施される（インデックスが存在しないと想定する）。この例では、例えば、第１のタプルがビーＩＤ７に関連付けられる。このタプルが関係からフェッチされると、ビーＩＤは、「記憶されたタプル」とともにＧＣＬルーチンへ送られる。このルーチンは、ビーＩＤ７を使用して、７番目のデータセクションを特定し、ハードコードされた値をフェッチする。このルーチンは、オフセットも計算し、カタログを参照することなく、ハードコードされていない属性の値を抽出する。最後に、ルーチンＧＣＬは、その型がホストＤＢＭＳによって内部定義される、配列を組み立て、この配列内のそれらの対応するスロットに、ハードコードされた値および入力タプルから抽出された値を入れる。この配列は、次いで、ルーチンＧｅｔＣｏｌｕｍｎＴｏＳｔｒｉｎｇに渡されて、「戻されたタプル」に変換され、ハードコードされた値がハイライトされる。
タプルビーが起動された場合であっても、クエリ評価は従来の手法と同じ方式で従来どおり実行されることに注意されたい。すなわち、ＤＢＭＳのいかなる部分のアーキテクチャを変更する必要性がないばかりか、マイクロ特化に適するようにクエリ言語を変更する必要性もない。
タプルビーは、ヌル値（複数可）を含む属性（複数可）を有するか、各属性の型、属性の数、およびタプル内部の各属性の値の場所等、特定のタプルの仕様を利用することができるため、非常に効率的である。
ＤＢＭＳ内の汎用コードをスキーマ内またはタプル内であっても存在する不変量に合わせてカスタマイズされた特化コードに置換するプロセスは、より特化され、そのためにより効率的である、コード［２、１０］を示すために、変数の値に関する知識を使用するコンパイラ最適化と同様である。マイクロ特化は、ビーを実行時不変量に関連付けることによって、高度に積極的な特化および定数畳み込みを可能にする。
５．２ 関係ビーを作成する
特定の関連ビーのソースコードの作成は第２項に上述した。ここでは、汎用コードブロックを、ビーソースコードを作成するために利用される、特化コードスニペットにどのように変換するかに関して、より一般的な検討を示す。
上記のリスト１において、２０〜４１行目のコードブロックは、リスト２の６行目等、属性の型にしたがって特化され、代入文に変換される。この変換は、この特定の例では２つのステップで実施されることに注意されたい。最初のステップでは、究極的に現在の属性のオフセットがキャッシュされているかどうかを検証し、キャッシュされていない場合はオフセットを演算するという、リスト１の２０〜３６行目のコードブロックは、リスト２の６行目の＋４によって示されるように、特化コード内の現在の属性のオフセットに対応する実値に変換される。２番目のステップでは、タプルから属性値をフェッチする、リスト１の３７行目のコード文は、属性型特異コードスニペットに変換される。この場合、４バイトの整数属性は、リスト２の第６行目のｉｎｔ＊キャスト文によってフェッチされる。
この特定の事例研究において、汎用コードブロックを特化コードスニペットに変換する際の複数のステップは、得られるコードの複雑度を抑制し、生成される実行可能コードの性能も最大限にするように、ソースコードのロジックおよび構造の手動解析によって結合される。しかしながら、より一般的な事例では、特に、変換がより系統的様式で実施される場合、手動解析が存在しないかもしれない。代わりに、第４．３．４で検討されるように、元のコードを変換して特化スニペットを生成するために、ソースコード変換機構を採用することができる。次いで、別のステップとして、マッピングされたコードスニペットに最適化を適用することができる。
５．３ タプルビーを作成する
第２項に記載される事例研究において、属性型特異のビールーチンのインストールを示すために順序関係を利用した。この関係では、ｏ＿ｏｒｄｅｒｓｔａｔｕｓ、ｏ＿ｏｒｄｅｒｐｒｉｏｒｉｔｙ、およびｏ＿ｓｈｉｐｐｒｉｏｒｉｔｙ属性は全て、小さいドメインの離散値を有し、このために、タプルビーが適用されることが可能であることを見出した。タプルビーの適用を促進するために、リスト６において利用されたＣＡＲＤＩＮＡＬＩＴＹキーワードによって示されるように、構文拡張によって順序関係を作成するためのＤＤＬ文を注釈する。
ＣＡＲＤＩＮＡＬＩＴＹの使用は「注釈」と呼ばれる。このような注釈の効果は、注釈された属性のドメインサイズ、すなわち、離散値全ての数を指定することである。上記の例において、属性ｏ＿ｏｒｄｅｒｓｔａｔｕｓ、ｏ＿ｏｒｄｅｒｐｒｉｏｒｉｔｙ、およびｏ＿ｓｈｉｐｐｒｉｏｒｉｔｙのドメインサイズは、それぞれ、３、５、および１である。１組の注釈された属性は、属性特化の候補と考えられる。我々の現在の実装においては、特化のためにＩＮＴ、ＣＨＡＲ、およびＶＡＲＣＨＡＲ型をサポートする。
注釈は、小さい濃度を有する「性別」等の属性を指定するために、タプルビーの作成において使用される。注釈は、ＤＢＡによって明示的に指定することができるか、または（ＳＱＬドメインから等）推論することができる。ビー構成グループの残りの構成要素は、関係のスキーマの変更によってトリガされる、ビー再構築である。
現在の実装は、候補属性のドメイン濃度に基づいて、自動的な属性特化を実施するために最長マッチを行うアルゴリズムを使用する。特化する属性（複数可）を決定するために、アルゴリズム（アルゴリズム１を参照）は最初に、指定された濃度によって候補属性を昇順にソートする。カウンタｐｒｏｄ＿ｃａｒｄは、ソートされた候補リストを反復する際に、選択された属性の濃度の積を追跡するために使用される。ｐｒｏｄ＿ｃａｒｄの値が、ビーの最大許可数である、ｍａｘ＿ｎｕｍ＿ｂｅｅｓに到達すると、アルゴリズムが終了し、最終的に特化するために選択された組の属性（複数可）を生成する。このアルゴリズムは、属性特化がＩ／ＯおよびＣＰＵ両方の効率を同時に達成することが可能であるため、特化のための属性数を最大にする。属性特化の詳細利点の解析は第８項に記載する。十分であるが、利用されたアルゴリズムは、属性のドメインサイズを考慮するだけでなく、属性型およびサイズ等、多様な他のファクタを考慮するように拡張されなければならない。
ＰｏｓｔｇｒｅＳＱＬのシステムカタログのデータ構造は、属性が特化されるかどうかを指定するフラグを追加することによって修正された。このフラグは、ビーが作成されるとき、特化属性値を取り扱うためにコードスニペットを必要とする属性（複数可）を決定するために参照される。次項には、特化される属性の構成を宣言して操作する、ＳＱＬ ＤＤＬ構文拡張について検討する。
属性の値に加えて、特に可変長属性の後に特定された属性のタプル内部のオフセットは、マイクロ特化を適用する不変量として利用することができる。具体的には、可変長属性が他の属性の前に出現する場合、可変長属性の後にある属性のオフセットは、各個別のタプルに対して、この属性の実値の長さに依存する。いうまでもなく、可変長属性は、定義によって１２８バイトの最大長を有する場合、残りの属性に対して、最大１２８の可能なオフセットが存在する。存在する可変長属性が多くなると、可変長属性の後に特定された属性のオフセットの可能な合計数は、その前の可変長属性全ての長さの積である。このような特化は、得られるタプルビーのコードサイズをさらに削減し、それらの効率を向上することができる。しかしながら、必要なタプルビーの合計数は急激に増大する可能性がある。さらに、属性値特化およびオフセット特化を比較すると、前者は、関係から特化属性を排除することによって、ＣＰＵ時間を向上するだけでなく、Ｉ／Ｏオーバーヘッドも削減する。このため、属性値特化は、オフセット特化よりも優先されるべきである。
タプルの他の特化の機会として、特定のタプルが暗号化を必要とするかどうか、またはどのような種類の暗号化が採用されるか、または一部または全ての属性が圧縮されるかどうかが挙げられる。
関係あたりの最大許可タプルビーの数は、エンジニアリングの考慮に基づいて２５６に制限された。もちろん、マイクロ特化を適用するために多種の値を利用することができる。一般に、可能なビーの数は、実行時不変行であるそのような変数の発生によって決定される。マイクロ特化を適用する際の１つの課題は、これらの不変量を識別することである。このような実行時不変量をどのように体系的に識別するかの検討は、第９項に記載する。
５．４ タプルビーをインスタンス化する
第３．２項で検討したように、多数のタプルが同じタプルビーを共有することができる。さらに、タプルはすべて、実際には、ＧＣＬ等、同じ関係ビールーチンを共有することができる。多様なタプルビーの間の相違は、データ値である。クラスタ化された記憶は、個別のデータ値全てに対して作成される。この記憶域は、「データセクション」と呼ばれる。各データセクションは、わずかな属性値を含み、小さい。データセクションが、例えば、一括ロード中に頻繁に作成されるとき、メモリ割り当てを起動するオーバーヘッドは高価になり得る。スラブ割り当て［１］技法は、データセクション作成の前に、メモリ割り当てを取り扱うために適用される。本実装において、ビールーチンが作成されると、ビーキャッシュを記憶するために３つのメモリページが割り当てられ、その中にビールーチンがシーケンシャルに記憶される。次いで、新しいタプルビーが生成されると、ルーチンセクションの後に、データセクションが作成され、記憶される。新しいタプルが必要かを決定するために、特化される属性の値は、シーケンシャル様式で既存のデータセクション全てに対して検証される。このようなシーケンシャルチェックは効率が低い。いずれにせよ、ビーＩＤの設計に起因して、各関係には最大２５６のタプルビーが許可されるため、既存のデータセクションを全てを検証することは、相当なオーバーヘッドではない。ＴＰＣ−Ｈベンチマークのためのビーキャッシュのサイズの要約は、第８．１．５項に記載される。作成されるデータセクションが多くなると、ビーキャッシュのサイズが８ＫＢ（２ページ）を超えた場合、新しいページが許可される。ここでも、データセクションの小さいサイズおよびタプルビーの合計数が小さいことから、ＴＰＣ−Ｈベンチマークの各関係に対して全てのビーを保持するには、２ページだけのメモリページで十分であり、そのため、追加のメモリ割り当ては不要である。タプルビー作成のオーバーヘッドを数量化するために、第８．１．５項には詳細の実行プロファイル解析が記載される。
タプルビーが特定のタプルのためのクエリに対して適切な値で応答できるように、データセクションにアクセスするために、関係ビールーチンは、リスト２の７、１９、および２６行目に示されるように、特化属性に対して「穴」を有するように修正される。ｂｅｅ＿ｉｄ引数は、タプルビーが関連付けられるデータセクションを識別するために使用される。したがって、各タプルとともにビーＩＤを記憶することが必要である。ＰｏｓｔｇｒｅＳＱＬに実装されたタプルヘッダーが１バイトの自由空間を有することから、ビーＩＤは、各タプルのヘッダーに隠すことができ、このため、追加の空間要件は全く発生しない。ビーＩＤは、限定された値ドメインを含む属性だけが特化されるべきであるという点で十分である。発明者のＴＰＣ−Ｈベンチマークの経験に基づき、関係によって必要とされるタプルビーの最大数は、８つの関係の間では２８である。リスト２に示されるマジックナンバー１０００、１００１、および１００２は、正しいデータセクションのアドレスが特定のタプルビーでインスタンス化できるように、プレースホルダーを識別する際に使用される。
５．５ 関係およびタプルビーのコストとメリット
関係およびタプルビーは、関係が定義されるときに作成、生成される。ＤＢＭＳ実行時にはコンパイラを起動するオーバーヘッドが導入されるが、関係の作成は、ＤＢＭＳユーザによって実施されるインタラクティブタスクである。したがって、関係の作成は、性能が重視されるタスクとは考えられず、関係およびタプルビーを生成するコンパイルのオーバーヘッドは許容することができる。
関係およびタプルビーは、クエリ評価時にＤＢＭＳによって直接起動され、したがって、このようなビーを管理するための追加のオーバーヘッドは、クエリ評価時には全く導入されない。タプルビーに関して、これらのインスタンス化は、前述のように、一括ロード等、修正時に発生する。大型の関係では、タプルビーのインスタンス化のオーバーヘッドは、事実、タプルビーによって実現されるＣＰＵおよびＩ／Ｏ両方の節約によって補償することができる。ところが、わずかなタプルだけを含む関係では、タプルビーをインスタンス化するオーバーヘッドは、節約を超える可能性がある。しかし、わずかなタプルを含む小さい関係を一括ロードする際、実行時間はそもそも顕著ではない。したがって、タプルビーをインスタンス化するオーバーヘッドは無視することができる。
第６項：クエリビーの詳細
マイクロ特化を適用する原則は、関係ビー、タプルビー、およびクエリビー全体で類似し、最初に、クエリ評価ループ内部で実行時不変量を識別し、次いで、これらの不変量への不要な参照を排除する。しかしながら、不変量の型および発生源の相違に起因して、クエリビーは、関係およびタプルビーとは区別される様式で適用される。クエリビーを適用する機構を詳細に示すため、リスト７に示されるように、例として、ＴＰＣ−Ｈベンチマークからクエリ１４の別の事例研究が示される。
元のクエリ１４は、累積を含む、複雑なＳＥＬＥＣＴ節を含む。関数の累積によるマイクロ特化がまだ調査されていないことから、ＳＥＬＥＣＴ文は、単純な属性プロジェクションに変換される。図６には、グラフでクエリ計画３１２が示される。計画３１２によって示されるように、内部関係部分が最初にメモリ内へハッシュされる。指定された述語を満たす外部の関係行項目からフェッチされた各タプルの場合、内部ハッシュ表に対してハッシュ結合が実施される。内部および外部両方のタプルからの結合キーが一致すると、ＳＥＬＥＣＴ文によってプロジェクトされた属性が戻される。
このクエリにクエリビーを適用する際、各計画演算子は、その演算子に特化する特定のクエリビーを必要とする。例えば、スキャンは、スキャン方向およびスキャンキーの存在を含む、いくつかの実行時不変量を含む。マイクロ特化は、複数のバージョンの特化されたスキャン演算子（関数）を生成するために、これらの値に適用され、各バージョンが特定の方向ならびにスキャンキーの存在（または不在）を処理する。同様に、マイクロ特化は、各演算子の特化コードを生成するために、このクエリ計画全体に適用される。
このクエリは、普通のＰｏｓｔｇｒｅＳＱＬおよびビーが有効になったＰｏｓｔｇｒｅＳＱＬ両方で実行される。クエリを実行時、両方のＤＢＭＳによって生成されたクエリ計画が同一であることが確認された。実行時間（ウォームキャッシュ使用）は、それぞれ、前者のＰｏｓｔｇｒｅＳＱＬでは１２２０ミリ秒、後者のＤＢＭＳでは９６１ミリ秒であった。性能は、２１％向上した。
６．１ クエリビーの種類：事例研究
このクエリの各計画演算子でマイクロ特化がどのように適用されるかの詳細をここに記載する。
６．１．１ スキャンクエリビー
前述のように、関係スキャン演算子の汎用実装は、複数の可能なケースを処理するための分岐文に依存する。第１に、前方、後方、および移動なしを含む、スキャンの方向には、３つのコード分岐が必要である。第２に、関係スキャンが実行されると、スキャンされた関係の属性のうちの１つに関連する述語が存在する場合、スキャンキーが存在する。したがって、２つのコード分岐が必要である。さらに、関係が空であるかに依存して、関係が空の場合、直接戻る文が実行されるように、２つのコード分岐が実装される。
個別のクエリの評価中、実行パスが必ず一意であることが見出された。すなわち、分岐文に含まれるこれらの変数は実際には不変量である。例えば、スキャン操作の方向は、クエリの実行中は変更されず、また、述語の存在は、関連のスキャンキー処理が必要となるかどうかを判定する。一般に、クエリ毎に、関係スキャン演算子の汎用コードの小さい部分だけが実行される。
これらの発見に基づいて、スキャンクエリプロトビー全てが構築され、各々は特定のケースに対応する。前述のように各変数に対するコード分岐の数から、合計で１２（３×２×２）のバージョンのプロトビーが必要である。関係が空である場合、スキャン方向およびスキャンキーを処理する必要性は存在しないことに注意されたい。これは、必要なプロトビーバージョンの合計数は、空でない関係を処理するために６つのプロトビー、および空の関係のための１つのプロトビーを含む、７つであることを示す。
これらの過剰な分岐文およびコード分岐自体を同時に削除することで、コードサイズが削減し、コードの実行効率が向上する。
６．１．２ ハッシュクエリビー
ハッシュ演算子が実行されると、最初に、このハッシュ演算子の下の子計画ノードから物理タプルを抽出する。子計画ノードの種類に依存して、このタプルは、スキャン演算子から直接フェッチされる、内部タプルとして戻される、または外部タプルとして戻されることが可能である。クエリ計画の特定のハッシュ演算子について、その子計画ノードの種類、したがって、関連するタプルの入力源は、クエリ評価中不変量である。さらに、各タプルからハッシュされる属性の数もまた定数であり、クエリ計画に組み入れることができる。
ハッシュ演算子のタプルフェッチコードは、タプルが正しいソースから検索されるように指示するために、ｓｗｉｔｃｈ文を利用する。ｓｗｉｔｃｈ文が排除され、３つの個別のバージョンのハッシュクエリプロトビーが構築された。
別の特化機会は、ハッシュ演算に存在する。多様な型の値をハッシュするには、多様な演算アルゴリズムが求められる。例えば、文字列をハッシュすることと整数をハッシュすることには、異なる手法が必要である。ＰｏｓｔｇｒｅＳＱＬに既に存在する型特異演算に対する最適化は、関数ポインタを利用することである。文字列ハッシュを実施する関数は、クエリ計画生成中にポインタの形でハッシュ演算子に関連付けることができる。この手法によって、実行時に適切なコード分岐に実行を指示する効率の低いスイッチ文の必要性を排除する。しかし、関数ポインタは、間接的な関数呼び出しによってのみ起動することができ、クエリ評価ループ内で蓄積されると相当なオーバーヘッドとなり得る。
関数ポインタを利用する代わりに、そのような間接的起動文それぞれが、関連するダミーのターゲットアドレスを用いて直接的な呼び出し命令に変換された。ダミーアドレスは、オブジェクトコードから容易に識別できる一意の整数である。実行時に、これらのマジックナンバーは、関数の実際のアドレスと置換された。したがって、間接的呼び出しは、ビーインスタンス化の間に直接的関数呼び出しと置換され、プロトビーが最終の実行可能ビーに変換された。
６．１．３ ハッシュ結合クエリビー
ハッシュ結合演算子の場合、多くのシナリオは、汎用実装で処理されることが必要である。第１に、左側結合、セミ結合、およびアンチ結合等の様々な種類の結合は、実行時に異なる実行パスをとる。第２に、ハッシュ結合演算子は、内部サブ計画および外部サブ計画ノードから、それぞれ、２つのタプルを受け取る。このようなノードそれぞれは、関連するタプルをフェッチするために異なるルーチンが必要な場合がある。例えば、外部サブ計画は、ハッシュ演算子またはスキャン演算子のいずれかであり得る。サブ計画ノードの型は、ＰｏｓｔｇｒｅＳＱＬのＰｌａｎＳｔａｔｅデータ構造によって提供される型という名前の変数によって識別される。究極的には複雑なｓｗｉｔｃｈ文である、ディスパッチャは、サブ計画ノードを認識し、対応するタプルフェッチ関数を起動する。さらに、結合キー比較は、関数ポインタの起動に関与する、別の型特異演算である。
結合の型は、クエリ計画によって決定され、クエリ計画が演算されると、内部および外部両方のサブ計画の種類もまた不変量である。ＰｏｓｔｇｒｅＳＱＬは、８つの型の結合を定義することから、８つのバージョンのハッシュ結合クエリプロトビーが構築された。ディスパッチャは、ここでも、実行時に適切なタプル処理関数のアドレスによって置換される、マジックナンバーを利用することによって排除された。最後に、結合キー比較関数の起動は、直接関数呼び出しに変換された。得られた結合評価クエリビールーチンは、「結合評価（ＥｖａｌｕａｔｅＪｏｉｎ）」（ＥＶＪ）と呼ばれる。
６．１．４ 述語クエリビー
述語評価は、述語に型特異比較も関与する、結合キー比較に類似する。このため、同じ技法は、プレースホルダーとして比較関数のアドレスを含む述語クエリプロトビーを生成するために適用される。加えて、ディスパッチャは、述語の中で、タプルがｌｉｎｅｉｔｅｍ関係からフェッチされるたびに「１９９５−０４−０１」等、定数オペランドを抽出するために利用されることが見出された。この値を毎回抽出する代わりに、各述語クエリビーは、値フェッチコードを削除することによって、単一の述語オペランドに特異であるようにカスタム化される。代わりに、各述語クエリビーに対して、オブジェクトコード内で、オペランドを表す別のマジックナンバーを実値で置換する。この新しいマジックナンバーは、述語比較関数への入力引数のうちの１つとして、述語クエリプロトビーのソースコードで指定される。得られるコードは事実上、値が述語評価コードにハードコードされていることに等しい。述語評価クエリビールーチンは、「ＥｖａｌｕａｔｅＰｒｅｄｉｃａｔｅ」（ＥＶＰ）と呼ばれる。
６．１．５ クエリビーの他の機会
クエリビーを識別することは、クエリの評価中に存在する実行時不変量を発見することが必要である。このような不変量は通常、データ構造内に特定される。実際に、ここまでクエリビーの形でマイクロ特化が適用される不変量全ては、ＰｏｓｔｇｒｅＳＱＬに実装された内部データ構造内に存在する。ＰｏｓｔｇｒｅＳＱＬ内部には、７０を超えるこのようなデータ構造が見出された。これらのデータ構造の各々は、１つ以上の特定のクエリ計画演算子によって利用される。クエリビーは究極的には、広範囲のクエリにわたるマイクロ特化の性能向上を最大限にするために、これらデータ構造全てで作成することができる。
６．２ クエリビーの作成と生成
クエリ計画演算子にマイクロ特化を適用するための機会は、第６．１項で導入された。ここでは、クエリビーのインストールに関連する特定の機構を中心に記載する。
不変量がコントロールコンストラクトに出現し、この不変量が、２、３の値だけに関連することが知られる場合、このような分岐文および関連の分岐は、特化コードから削除することができる。
第３．４項において、結合演算子クエリビー等のクエリビーに対して、多様な結合型に対応するコード分岐は、クエリ評価時にソースコードのコンパイルが不要であるように、プロトビーに予めコンパイルされることを思い出されたい。
ＤＢＭＳでは、ネストループ結合、ソートマージ結合、およびハッシュ結合を含む、３つの結合アルゴリズムが通常適合される。ＰｏｓｔｇｒｅＳＱＬでは、結合型は、３つの種類の結合全てで共通の不変量である。型は、内部結合、外部結合、セミ結合、およびアンチ結合を含む。これらの型の結合の間の違いは、実装という点では、多様な一致要件を処理するために、各型が個別のコードパスに依存することである。例えば、アンチ結合およびセミ結合を処理するために（前者は、内部関係から一致するタプルを全く有さない、外部関係におけるタプル全てが得られ、後者は、外部関係のタプル全てが得られ、各タプルは内部関係から一致したタプルを有する）、ＰｏｓｔｇｒｅＳＱＬは、リスト８に示される実装（スニペット）を利用する。
現在関与する結合型に対応しない、ｊｓ．ｊｏｉｎｔｙｐｅ変数および関連の分岐の評価は、結合の種類がクエリ計画で知られている場合、定数折り畳みを介して排除することができる。同様に、結合アルゴリズムでは、ＪＯＩＮ／ＯＮまたはＪＯＩＮ／ＵＳＩＮＧから発生する制限条件である、ｊｏｉｎ ｑｕａｌｓの存在、およびＷＨＥＲＥ節から発生する暗示的にＡＮＤされた制限条件である、ｏｔｈｅｒ ｑｕａｌｓの存在である、２つの他のそのような不変量変数が利用された。各々２つの個別の値（０および１）を許可する、両方の存在フラグは、マイクロ特化を適用するために利用される。このため、各結合アルゴリズムには、１６の個別のプロトビー（第６．１項で導入されたように）が必要であり、各々は、これらの不変量の値の単一の可能な組み合わせに対応する。１６のバージョンのソースコードをプロトビーに作成する代わりに、リスト９に示されるように、汎用バージョンのプロトビーのソースコードが（各々の結合アルゴリズムに対して）コンパイルされ、コンパイラを起動時にＤオプションを利用することによって１６の値が組み合わされる。例として、リスト９に示されるコードが、オプション、−Ｄ ＪＯＩＮＴＹＰＥ＝ＪＯＩＮ−＿ＡＮＴＩを用いてコンパイルされた場合、４行目のｉｆ文が排除されることに注意されたい。さらに、８行目および９行目に示されるｉｆ文も、その関連分岐とともに、排除される。究極的には、−Ｄオプションによって、コンパイラは、不要な条件チェックおよび関連の基本的なブロックを排除することができ、高度に最適化されたプロトビーが得られる。プロトビーは、ビーキャッシュに連続的に記憶される。特定のプロトビーを特定するために、不変量の値が利用され、各プロトビーに対して、インデックスのように、値の一意の組み合わせが存在する。例えば、結合が、値３によって内部的に表現される型ＪＯＩＮ＿ＡＮＴＩである場合、この結合が、値１によって示されるｊｏｉｎ ｑｕａｌｓを含むが、０によって示されるｏｔｈｅｒ ｑｕａｌｓは含まない場合、この特定の結合のインデックスは、３×４＋１×２＋０×２によって計算される、１４である。４は、可能な結合型の数であることに注意されたい。同様に、２は、それぞれ、ｊｏｉｎ ｑｕａｌｓおよびｏｔｈｅｒ ｑｕａｌｓの存在の可能なケースの数を表す。
コンパイルビーは、第３．２項で導入された。このようなビーは、究極的に型特異比較関数を含み、直接関数呼び出しを介して、クエリビーによって実行時に起動される。事実、コンパイルビーは、コンパイルビーのオブジェクトコードをインラインすることによってクエリビーに組み入れることができる。コンパイルビーをインラインすることによって、関数呼び出しのオーバーヘッドを排除し、これによって、クエリビーの効率をさらに向上することができる。
６．３ クエリビーによるクエリの評価
ここまで、マイクロ特化が適用可能である多数の場所（演算子）が確認された。特定のクエリ評価を実施するために、いくつかのクエリビーをインスタンス化してから、次いで組み合わせる機構をここで検討する。
クエリ評価中、クエリ計画が決定された後、そのノードは全て、クエリ評価のために不変量となる。クエリビーは、選択されたプロトビーに基づいてインスタンス化される。クエリビーは、最初に、正しいバージョンのプロトビーを選択し、プロトビーを実行可能メモリ領域にロードすることだけによって、インスタンス化される。全てのバージョンの各プロトビーは、ポインタ配列に記憶され、各ポインタは、各バージョンのプロトビーコードの開始アドレスを参照する。正しいハッシュ結合プロトビーを選択するために、対応するバージョンをインデックスするように０から７の範囲である整数値である、結合型が利用される。
次のインスタンス化ステップは、オブジェクトコード操作が必要である。図６に示されたハッシュ結合演算子を例とする。プロトビーが選択された後、前述のように、マジックナンバーは、ターゲット関数の正しいアドレスと置換される。こうして、実際のクエリビーがインスタンス化される。インスタンス化のステップは、実際に、動的リンキングに非常に類似する。ハッシュ結合演算子等の特定の演算子がクエリ計画で複数回出現する場合、ハッシュ結合プロトビーは、複数回インスタンス化されることが必要で、それぞれ、個別の計画ノードに関連するビーが得られる。
得られたクエリビーは、クエリ計画の実行可能コードを形成するために合わせてステッチングされる。従来の実装は、クエリ計画全体を評価する際に、適切な計画演算子を特定し、起動するために、複雑なディスパッチャに依存する。代わりに、構築された計画演算子特異のクエリビーが、ここでも、それらの所望される子クエリビーを用いてビーをインスタンス化することによって、合わせてステッチングされる。クエリビーのソースコードのスニペットの例は、以下のように、このステッチング機構の説明を助けるために提供される。
（（ＦｕｎｃｔｉｏｎＣａｌｌＩｎｆｏ）ｐｒｅｄｉｃａｔｅ−＞ｘｐｒｓｔａｔｅ．ｊｏｉｎ＿ｉｎｆｏ−＞
ｆｃｉｎｆｏ＿ｅｖｊ）−＞ａｒｇ［ＯＵＴＥＲＡＲＧＮＵＭ］ ＝
（（Ｄａｔｕｍ（＊）（ＴｕｐｌｅＴａｂｌｅＳｌｏｔ＊， ｉｎｔ， ｂｏｏｌ＊））０ｘ４４００４４）（
ｅｃｏｎｔｅｘｔ−＞ｅｃｘｔ＿ｏｕｔｅｒｔｕｐｌｅ，
０ｘ１０１，
＆（（ＦｕｎｃｔｉｏｎＣａｌｌＩｎｆｏ）ｐｒｅｄｉｃａｔｅ−＞ｘｐｒｓｔａｔｅ．ｊｏｉｎ＿ｉｎｆｏ−＞
ｆｃｉｎｆｏ＿ｅｖｊ）−＞ａｒｇｎｕｌｌ［ＯＵＴＥＲＡＲＧＮＵＭ］）；
この特定の関数起動文（ダミーアドレス０ｘ４４００４４まで）は、実際に、子計画ノードに対応するクエリビーを起動し、外部サブ計画からタプルをフェッチすることに注意されたい。実行時に、マジックナンバー０ｘ４４００４４は、実際の子ビーのアドレスと置換される。
クエリビー全てのインスタンス化に２、３のメモリコピーおよびいくつかのインプレースメモリ更新しか必要としないことから、このように、クエリビーのインスタンス化は非常に効率が高く、最小のオーバーヘッドを発生する。
６．４ クエリビーを起動する
リスト１０には、クエリビーを起動する、ＥｘｅｃＥｖａｌＯｐｅｒｆｕｎｃｔｉｏｎからのコードスニペットが示される。クエリ評価中、この特定の関数は、計画演算子を実行するために必要な情報を初期化するために、１回呼び出される。この関数は、具体的には、７行目に示されるように、ｆｃａｃｈｅ−＞ｘｐｒｓｔａｔｅの構造体のｅｖａｌｆｕｎｃフィールドを初期化する。ｅｖａｌｆｕｎｃフィールドに渡された関数アドレスは次いで、タプル毎のベースで、その後の呼び出しによって起動される。この関数は、１２行目で第１のタプルを処理するために呼び出され、実際の評価関数によって計算された値を戻す。
評価関数は、８行目に示されるにように、クエリビーに置換される。この例では、クエリビーは、特定の述語を評価するためである。クエリ準備段階で、インスタンス化されたクエリビーのアドレスは、各クエリ計画ノードが、存在する場合、特定のクエリビーによって置換できるように、クエリ計画に関連するデータ構造、すなわちｘｐｒｓｔａｔｅのデータ構造に記憶される。ビールーチンは、元のＤＢＭＳコードに対する変更を抑制するために、普通の関数起動と同じ関数呼び出し署名を有することに注意されたい。
６．５ ホットスワップビー
ここまで、クエリ評価中に定数値をとる変数という、不変量にマイクロ特化を適用することを中心とした。ここで、検討は、各々がクエリ評価中に値が判定される、変数に一般化される。
例として、スキャン演算子、特に、リスト１１に示される２つのコード分岐を検証する。ｒｓ＿ｉｎｉｔｅｄ変数は、スキャン演算子が初期化されているかどうかを示す。すなわち、この変数は、現在のタプルが、クエリ内部でスキャンされた関係からフェッチされている最初のタプルであるかどうかを表す。この変数は次いで、クエリの残りの部分では、真が代入される。定義では、この変数は、厳密には不変量ではない。しかし、この変数は、最初のタプルがフェッチされた直後に定数であることが知られるという事実によって、条件文を評価することは、タプルの残りの部分では冗長になる。
このため、２つの追加のバージョンのスキャンクエリプロトビーが生成される。第１のバージョンは、上記のコードの第１のコード分岐を含み、第２のバージョンは、他のコード分岐からのコードを含む。空以外の関係を処理するために、既に６つのバージョンのスキャンクエリプロトビーが存在することから、合計で１３（空の関係を処理するバージョンを含めて、６×２＋１）のバージョンが必要となる。
インスタンス後にオブジェクトコードが修正されるほかのビートは異なり、インスタンス化されたスキャンクエリビーは、自己修正の対象となる。このような機構は、図７に示されるコールグラフ３２０で示される。この図において、ビー３２４、３２６、および３２８は、矩形として表される。普通の実装において、関数ＳｅｑＮｅｘｔ３２２は、ヒープファイル内の次のタプルをフェッチするために、関数ｈｅａｐ＿ｇｅｔｎｅｘｔ３２４を呼び出す。関数ｈｅａｐ＿ｇｅｔｎｅｘｔは次いで、現在スキャンされているページ上に特定された実際のタプルを呼び出すために、ｈｅａｐｇｅｔｔｕｐ＿ｐａｇｅｍｏｄｅという関数を呼び出す。ｈｅａｐ＿ｇｅｔｎｅｘｔが初めて呼び出された場合、いくつかの初期化が実行される必要がある。図７において、ｈｅａｐｇｅｔｔｕｐ＿ｐａｇｅｍｏｄｅ＿ｉｎｉｔは、含まれた初期化コード分岐だけを含む、特化されたバージョンのｈｅａｐｇｅｔｔｕｐ＿ｐａｇｅｍｏｄｅを表すビー３２６である。同様に、ｈｅａｐｇｅｔｔｕｐ＿ｐａｇｅｍｏｄｅ＿ｒｅｇｕｌａｒは、他のコード分岐だけを含む。ｈｅａｐｇｅｔｔｕｐ＿ｐａｇｅｍｏｄｅ＿ｉｎｉｔの実行中、ｈｅａｐ＿ｇｅｔｎｅｘｔビー３２４のオブジェクトコードは、＿ｉｎｉｔバージョンへの元の呼び出しが、＿ｒｅｇｕｌａｒバージョンにホットスワップされるように、編集される。ホットスワップは、関数呼び出しアドレスのインプレース更新、この場合、＿ｉｎｉｔビー３２６への呼び出しを＿ｒｅｇｕｌａｒビー３２８への呼び出しに変更することによって、簡単に実行される。そこから、後のビー３２８が呼び出される。値のシーケンスに対して、複数のホットスワップが存在し、各々、次の特化バージョンへの呼び出しにスワップする。ホットスワップは、スワップされるビーへの呼び出しもビーであることが必要であるため、この呼び出し元ビーを修正することができる。このため、大型のビーは命令キャッシュ圧力を導入する可能性があるため、呼び出し元ビーは関数全体である必要はない。代わりに、ビールーチンは、ホットスワップしているビーを起動する関数呼び出し文だけの大きさに小さくすることができる。
ＰｏｓｔｇｒｅＳＱＬソースコードのより詳細研究によって、ソートマージ結合演算子もこのような特化から利益を受ける可能性があることが明らかになった。ソートマージ結合アルゴリズムにはいくつかの状態が関与し、各々は、汎用関数の個別のコード分岐に関連する。ソートマージアルゴリズムの実行は、これらの状態の間で切り替わり、各々の状態は固有の状態に続く。
このような特化がどの状況に適用されるべきかを示す２つの単純な規則が示唆される。まず、分岐文で使用される変数に関連する個別の値はわずかしか存在しない。第２に、この変数は、実行パス選択がこの変数の値に依存するように、分岐文で参照されなければならない。
一般に、実行時に必要なクエリビーだけがインスタンス化され、起動されるので、作成および生成することができるクエリビーの数に制限は存在しないことに注意されたい。このため、クエリ評価性能は、有効なクエリビーの合計数によって影響されず、どのクエリビーが作成されるかを決定する際にトレードオフは存在しない。マイクロ特化を適用するための不変量の選択を最適化する、アルゴリズム１に類似のアルゴリズムは、クエリビーによって要求されない。
動的なオブジェクトコードの操作は、マルチスレッドのクエリ実行環境では、ホットスワップしているビーがビーのオブジェクトコードを更新するために、複数のスレッドによって起動されると、慎重に同期が処理されることが必要であるという懸念が生じる。しかし、ＰｏｓｔｇｒｅＳＱＬは、各クエリを実行するために１つのプロセスだけを採用するので、このような考慮は我々の実装では生じない。さらに、各クエリ評価は、クエリビーの個別のインスタンス化が必要であることから、コードの再入可能性は、オブジェクトコードが実行時に動的に修正される場合であっても、各スレッドがそれに固有のビーを利用するため、保存される。
ＣＡＬＬＧＲＩＮＤによって収集された実行時プロファイルを使用するクエリビーの性能利点をここで検証する。第１に、コンパイラの起動のオーバーヘッドは、性能解析に含まれないことを特筆する価値がある。これは、コンパイラはクエリ評価中には実行時に決して起動されないからである。代わりに、クエリ評価前にプロトビーがコンパイルされ、したがって、実行時に、実行可能なビーを動的にインスタンス化し、起動するオーバーヘッドはささいである。ＣＡＬＬＧＲＩＮＤによって収集された実行時プロファイルは、プロファイルツールによって採用されるサンプリングベースの機構に起因し、ビーをインスタンス化するためのレコードさえ含まない。
リスト１２およびリスト１３に示されるのは、それぞれ、普通のＤＢＭＳおよびビーが有効なＰｏｓｔｇｒｅＳＱＬ上で例示的なクエリを実行する際のプロファイル出力の抜粋である。表記Ｉｒは、実行された命令の数を表すことに注意されたい。プロファイル結果に示されるように、普通のＤＢＭＳは、合計で７４２９Ｍの命令を実行した。一方、ビーが有効なＤＢＭＳは、４９４０Ｍの命令を実行し、実行された命令の数が３４％削減した。
次に、性能向上を説明するために、特定の関数の命令カウントが確認される。最も顕著な向上は、ｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ関数からである。この関数は、物理的タプルをロング整数の配列に変換する。この関数は、クエリで参照される両方の関係において、各タプルに起動されることに注意されたい。したがって、この関数を特化することで、最も顕著な利点を達成する。リスト１３が示すように、ｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅは、それぞれ、０ｘ４４１ｂ３ｃ０および０ｘ４４２ｅ７ｃ０のメモリ内場所として表される、２つの関係ビーを起動することによって高度に特化される。このような特化の結果、クエリが実行された場合、合計で２０％の命令が削減される。
述語の存在は、マイクロ特化を適用するための別の機会を提供する。普通のＤＢＭＳ内のＥｘｅｃＭａｋｅＦｕｎｃｔｉｏｎＲｅｓｕｌｔＮｏＳｅｔｓ関数は、述語評価を実施する。対照的に、クエリに存在する２つの述語は、メモリ内のアドレスとして、リスト１３に示されるように、２つの述語ビーによって評価された。２つの述語クエリビーだけで、合計で約７％実行された命令を削減した。
各マイクロ特化は性能を向上するが、いくつかのマイクロ特化は、影響が小さい場合がある。ｈｅａｐｇｅｔｔｕｐ＿ｐａｇｅｍｏｄｅ関数は、関係をスキャンする役目がある。この関数の実装は、第６．５項で検討した。普通の実装において、この関数は、スキャンの方向を確認し、述語の存在をチェックすることが必要である。プロファイル結果が示すように、これらの不変量にマイクロ特化を適用することによって、その関数自体の命令の約３２％が削減される。１３８Ｍの命令の削減は、向上全体の約２パーセントである。普通の実装によって利用されたディスパッチャ、ＥｘｅｃＰｒｏｃＮｏｄｅ（プロファイル内では、２つのこのようなインスタンスが存在する）は、合計１１Ｍの命令に寄与する。ビーが有効なＰｏｓｔｇｒｅＳＱＬにおいて、このオーバーヘッドは完全に排除される。合計で、マイクロ特化が複数の演算子全体で積極的に適用された場合、比較的性能利点が低いクエリビーによって、さらに約７％の命令が削減された。
実行時にビーをインスタンス化することは、追加の命令が実行される必要があることに注意されたい。ただし、ＣＡＬＬＧＲＩＮＤは、この追加のオーバーヘッドはカウントするには小さすぎるため、このようなデータを収集することができなかった。
要約すると、クエリビーは、最初に、クエリ評価ループ中に不変量を識別することによって利用される。次いで、関連するプロトビーが、実行可能クエリビーとして動的にインスタンス化される。未使用のコード分岐を排除し、間接的な関数呼び出しを直接呼出しに変更する等、いくつかの最適化を適用することによって、顕著な性能利点を達成することができる。
６．６ クエリビーのコストとメリット
第３．４項で検討したように、クエリビーの作成および生成は、ＤＢＭＳがコンパイルされるときに実施される。すなわち、これらの２つのタスクによって導入されるオーバーヘッドは、コンパイル時のものである。
実行時に、クエリビーをインスタンス化するオーバーヘッドが導入される。したがって、クエリ評価中にクエリビーを起動することによって達成される性能利点は、大部分が、クエリのサイズ、すなわち、クエリの評価中に各クエリが何回実行されるかに依存する。クエリが小型の関係にある場合、クエリビー全てをインスタンス化するオーバーヘッドは、これらのビーが達成することができる実際の性能ゲインを超える場合がある。したがって、クエリ評価中にクエリビーが利用されるべきであるかの選択を行うために、クエリされる関係のサイズ、およびクエリ内の述語の選択性に基づいて、予想モデル等の機構が必要である。
第７項：キャッシュ圧力を緩和する
プログラムの実行中、実行された命令は各々、最初にＣＰＵキャッシュにフェッチされる。キャッシュ内のスロットは（Ｌ１キャッシュまたはＬ２キャッシュまたはＩキャッシュ）、キャッシュラインと呼ばれる、命令が特定された場所で、仮想メモリ空間内の命令のアドレスによって決定される。同じキャッシュ行を共有している複数の命令が実行されると、キャッシュ競合が発生し、高価なキャッシュミス違反となる（キャッシュ行の消去、およびメモリ階層内のより下位からフェッチされる命令）。
ＤＢＭＳでは、クエリ評価は通常、多数の反復から実行される相当量の命令が関与する。このクエリ評価コードの大量のフットプリントは、命令失敗違反に起因して、潜在的に、性能低下につながる可能性がある。ＧＣＣ等のコンパイラは、コードのローカル性を向上するために、基本ブロック順序変更技法を適用し、それによって命令キャッシュミスを削減するが、ＤＢＭＳがコンパイルされるときにビーが存在しないため、ビーコードは、この最適化による利益を受けない。このため、この課題に対応するために３つの効果的な手法が提供される。
クエリ評価中にビーを実行するキャッシュの効果を示すために、図８は、クエリの評価中の、ビーの多様な配置（ｘ軸によって示される）と、Ｉ１キャッシュミスのパーセント増加（ｙ軸によって示される）との間の関係の研究を示す。第８項に記載するように、実験マシンは、３２ＫのＩ１キャッシュが装備される。各キャッシュ行は６４バイトの幅で、キャッシュは４方向のセット関連性があることから、合計で１２８のキャッシュスロットが存在し、各々が４つのキャッシュ行からなる。１６の配置が、１２８の可能なキャッシュスロット全て全体で均一にサンプリングされる。すなわち、同じクエリが１６回評価され、各タイミングで、各クエリ評価中にビーの異なる配置が実行される。図によって示されるように、ビーが０ｘ１０および０ｘ４０のアドレスのキャッシュスロットにそれぞれ配置されると、Ｉ１キャッシュミスレートが抑制される。しかしながら、ビーが０ｘ６８に配置されると、キャッシュミスで１３０％を超える増加が観察される。一般に、命令キャッシュの全体的性能は、ビーの配置に対する感度が非常に高い。
キャッシュミスレートは、最適化されていないビー配置では顕著に増加し得るが、この特定のクエリでは実際の実行時低下はささいである。これは、図９に示されるように、ＴＰＣ−Ｈクエリのほとんどの全体的なＩ１キャッシュミスレートが約０．３％であるためである。このようなわずかなキャッシュミスレートが１３０％増加しても、クエリの実際の実行時間に関して顕著な影響はない。
しかしながら、多くのビーがクエリ評価に利用されると、特により複雑なクエリ内部またはより多くの実行時命令が関与するより高度なＤＢＭＳ内部では、ビーの不用意な配置は、実際の実行時性能に顕著な影響を与えかねない。事実、２２のＴＰＣ−Ｈクエリの中で１つの特定のクエリ（クエリ６）では、Ｉ１キャッシュミスレートが約１％、実行された命令が４．８ＢおよびＩ１キャッシュミスが４７Ｍであることが観察された。第７．３項で検討したように、適切なビー配置では、Ｉ１キャッシュミスレートは、わずか０．１％まで削減した。この削減は、高価なキャッシュミス違反に起因して、１５％を超える実行時間向上に変換された。したがって、キャッシュの圧力は、実行時性能に直接影響を与える重要な問題と考えられる。適切なビー配置を演算するために、３つの手法が提供される。
７．１ 呼び出し元の隣のローカル配置
プログラムを実行時の命令キャッシュミスレートを削減するために、コード生成時に適用される典型的なコンパイラ最適化技法は、生成された実行可能コードで基本的なブロックおよび関数の順序を変更することである。このコードレイアウト最適化は、最初に静的コールグラフを識別してから、次に生成されたコードで呼び出し元およびその呼び出し先を相互に隣り合わせに配置することによって達成される。アイデアは、これらの２つの関数が十分に小さく、キャッシュ全体を占有しないと仮定して、関数が別の関数を呼び出すと、それらをシーケンシャルに配置することによって、これらの２つの関数が相互にオーバーラップしない連続的キャッシュラインにマッピングされることになるということである。この手法は、２つの関数からの命令が同じキャッシュラインにマッピングされる可能性を効果的に削減することができる。
ＰｏｓｔｇｒｅＳＱＬ ＤＢＭＳおよびビーコードをコンパイルするために、ＧＣＣが使用されてもよい。ＧＣＣは、呼び出し先を呼び出し元の前に配置することによって、関数レイアウト最適化を実施する。同じ戦略はビーを配置するために採用された。ビー呼び出し元は、ＰｏｓｔｇｒｅＳＱＬ実行可能から容易に識別することができる。したがって、これらのビー呼び出し元のアドレスは、ＤＢＭＳコンパイル時に決定することができる。ビーを配置すると、キャッシュラインにマッピングすることによって、ビーの呼び出し元から２、３前のスロットである、メモリアドレスが選択された。スロットの数は、ビーのサイズによって決定される。
この配置では、クエリ６のＩ１キャッシュミスは、元の４７Ｍから１９Ｍに削減し、６０％のキャッシュミス削減となった。これで、クエリ６のＩ１キャッシュミスレートは、０．４％（１９Ｍ／４．８Ｂ）となった。
その簡易性および効率にも関わらず、この手法には欠点がある。クエリ評価によって実行される内部ループのコードは通常、キャッシュ内の大きいフットプリントを占める。このため、その呼び出し元だけを考慮してキャッシュ領域にビーを配置すると、ビーが何らかの他の頻繁に実行される関数とオーバーラップしてしまう場合があり、顕著なキャッシュ性能の低下になる。この懸念は、上記の手法が一般に適用可能ではないことを示す。技術的には、ビーのこのような配置は、一般に他のＤＢＭＳ関数に関わらず、ビー呼び出し元に対してローカルに限定される。この手法は、「ローカル手法」と呼ばれる。しかしながら、その簡易性のため、それでもビー配置の代替手法として検討される。
呼び出し元の隣のローカル配置の擬似コードを以下に示す。
ＰｌａｃｅＢｅｅｓ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ）
ｂｅｅｓ＿ｔｏ＿ｐｌａｃｅ＝ＩｎｓｔａｎｔｉａｔｅＢｅｅｓ（）；
ｆｏｒｅａｃｈ ｂｅｅ ｉｎ ｂｅｅｓ＿ｔｏ＿ｐｌａｃｅ
ｄｏ
ｂｅｅ＿ｃａｌｌｅｒ＝ＦｉｎｄＢｅｅＣａｌｌｅｒ（ｂｅｅ，ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ）；
ｍｅｍｏｒｙ＿ｏｆｆｓｅｔ＝ＢｅｇｉｎＡｄｄｒｅｓｓ（ｂｅｅ＿ｃａｌｌｅｒ）−ＳｉｚｅｏｆＢｅｅ（ｂｅｅ）；
ｃａｃｈｅ＿ｌｉｎｅ＝ＴｒａｎｓｌａｔｅＭｅｍｏｒｙＡｄｄｒｅｓｓ（ｍｅｍｏｒｙ＿ｏｆｆｓｅｔ）；
ＰｌａｃｅＢｅｅａｔＣａｃｈｅＬｉｎｅ（ｂｅｅ，ｃａｃｈｅ＿ｌｉｎｅ）；
ｅｎｄ ｆｏｒ
７．２ グローバル関数スコアベース配置
前述の手法の欠点を避けるために、ＤＢＭＳ内の関数全てをビー配置のグローバルビューとして考慮する。具体的には、実行可能コード全体が１２８のキャッシュスロット全てにマッピングされる。図１０は、累積キャッシュスロット参照ヒストグラムを示す。ｘ軸は、キャッシュスロット全てを表す。ｙ軸は、各個別のキャッシュスロットにマッピングされている関数の数を示す。
図１０に示されるように、それぞれ、０ｘ０７〜０ｘ１０および０ｘ５６〜０ｘ６０、に特定される、２つのキャッシュ領域３４０および３４２は、最小の数の関数を含む。このようなキャッシュ領域３４０および３４２は「谷」と呼ばれる。直感的な解決策は、これらの谷３４０および３４２にのみビーを配置することである。
しかしながら、このような配置戦略の制限は、特定の実行可能プログラムに対して、谷が必ず利用可能であることに保証がないことで、その場合、ビーのために実現可能な配置が存在しない。さらに、この戦略配置手法の別の欠点は、クエリ評価中に、ＤＢＭＳ内の関数全てが起動されないことであり、さらに、起動された命令の中で、それらの全てが実行時性能の影響という点で同等な重要性を持つわけではない点である。例えば、ＳＱＬパース関数によって起動される命令は、結合関数からの命令よりも重要度が低く、後で、ＤＢＭＳ操作中に後者よりも頻繁に実行される。図１０に示されるように、キャッシュスロット０ｘ１０では、最大数の関数が観察されるが、図８は、対照的に、最も少ないＩ１キャッシュミスは、まさにそのポイントで実行時に発生することを示唆する。
ビーがクエリ評価内部ループ内で頻繁に起動されることから、ビーの配置は特に、これも内部ループに存在する関数からの命令との競合を回避しなければならない。このような関数は、「ホットスポット」関数と呼ばれる。このようなホットスポット関数を検出するために、クエリ評価をプロファイルするためにＶＡＬＧＲＩＮＤが利用された。評価クエリでは、ＤＢＭＳの異なる組の関数が起動され得る。例えば、単純なスキャンクエリを評価する場合、テーブルスキャン関数だけが必要である。しかし、結合を含むクエリでは、テーブルスキャン関数だけではなく、起動された結合アルゴリズムの関数も必要とされる。内部ループの包括的な関数のセットをキャプチャするために、トレーニングサンプルとして、個別の特徴を有するいくつかのクエリのセットが作成される。
ホットスポット関数が識別されると、これらの関数のうちのより高い優先度を統合するために、スコアスキーマが変更される。ホットスポット関数の重要点は、より高いユニットスコアによって単純に表される。標準の命令（ホットスポットからではない）には、０．５のスコア（任意に選択された小さい数）が割り当てられ、ホットスポットからの命令には、各命令は１００のスコアが割り当てられる。これらの２つのスコア値の顕著なギャップは、頂点と谷との間の顕著な区別となり得て、谷の識別が容易になる。
この配置手法は、クエリ６を再び評価するために適用された。Ｉ１キャッシュミスにおいてさらなる５Ｍの削減が観察された。Ｉ１キャッシュミスレートはこれで０．３％で、１４Ｍを超えるＩ１キャッシュミスとなる。
グローバル関数スコアベース配置の擬似コードを以下に提供する。
ＣｏｍｐｕｔｅＦｕｎｃｔｉｏｎＳｃｏｒｅＨｉｓｔｏｇｒａｍ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ，ｑｕｅｒｙ＿ｌｏｏｐ）
ｈｉｓｔｏｇｒａｍ＝ＮＩＬ
ｆｏｒｅａｃｈ ｃａｃｈｅ＿ｌｉｎｅ ｉｎ ｃａｃｈｅ＿ｌｉｎｅｓ
ｄｏ
ｈｉｓｔｏｇｒａｍ［ｃａｃｈｅ＿ｌｉｎｅ］＝０
ｅｎｄ ｆｏｒ
ｆｏｒｅａｃｈ ｆｕｎｃｔｉｏｎ ｉｎ ＧｅｔＡｌｌＦｕｎｃｔｉｏｎｓ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ）
ｄｏ
ｉｆ ｆｕｎｃｔｉｏｎ ｉｎ ｑｕｅｒｙ＿ｌｏｏｐ
ｔｈｅｎ
ｈｉｓｔｏｇｒａｍ［ＢｅｇｉｎＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）．．ＥｎｄＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）］＝
ｈｉｓｔｏｇｒａｍ［ＢｅｇｉｎＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）．．ＥｎｄＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）］＋０．５
ｅｌｓｅ
ｈｉｓｔｏｇｒａｍ［ＢｅｇｉｎＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）．．ＥｎｄＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）］＝
ｈｉｓｔｏｇｒａｍ［ＢｅｇｉｎＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）．．ＥｎｄＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）］＋１００
ｅｎｄ ｉｆ
ｅｎｄ ｆｏｒ
ｒｅｔｕｒｎ ｈｉｓｔｏｇｒａｍ
ＰｌａｃｅＢｅｅｓ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ）
ｂｅｅｓ＿ｔｏ＿ｐｌａｃｅ＝ＩｎｓｔａｎｔｉａｔｅＢｅｅｓ（）；
ｑｕｅｒｙ＿ｌｏｏｐ＝ＥｘｔｒａｃｔＱｕｅｒｙＬｏｏｐ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ）；
ｈｉｓｔｏｇｒａｍ＝ＣｏｍｐｕｔｅＦｕｎｃｔｉｏｎＳｃｏｒｅＨｉｓｔｏｇｒａｍ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ，ｑｕｅｒｙ＿ｌｏｏｐ）；
ｆｏｒｅａｃｈ ｂｅｅ ｉｎ ｂｅｅｓ＿ｔｏ＿ｐｌａｃｅ
ｄｏ
ｃａｃｈｅ＿ｌｉｎｅ＝ＦｉｎｄＶａｌｌｅｙＣａｃｈｅＬｉｎｅ（ｈｉｓｔｏｇｒａｍ）
ｉｆ ｃａｃｈｅ＿ｌｉｎｅ ｉｓ ｖａｌｉｄ
ｔｈｅｎ
ＰｌａｃｅＢｅｅａｔＣａｃｈｅＬｉｎｅ（ｂｅｅ，ｃａｃｈｅ＿ｌｉｎｅ）
ｅｌｓｅ
ＰｌａｃｅＢｅｅａｔＣａｃｈｅＬｉｎｅ（ｂｅｅ，０）
ｅｎｄ ｉｆ
ｅｎｄ ｆｏｒ
７．３ プロファイル解析および内部ループ識別ベースのグローバル配置
上記の２つの手法には利点および欠点がある。第１の手法は、一般に適用するには、ローカルすぎる場合がある。他の関数を考慮せずにビー呼び出し元を考慮することで、キャッシュ効果は、既存のホットスポットおよび不適切に配置されたビーの競合によってさらに増幅される可能性が高い。
第２の手法の主な利点は、ＰｏｓｔｇｒｅＳＱＬ実行可能ファイル全体を考慮することで、解析を完全にする。しかしながら、静的命令マッピングには、重要ではない命令が大量に含まれる。この欠点によって、解析が不正確かつ困難になる。ホットスポット関数が優先付けられる場合でも、スコアスキーマは、谷を正確に識別するには、まだ粗すぎる。
したがって、クエリ評価中に実行される命令だけに注目することによって、実行時の谷をより正確に識別するために、プロファイル解析および内部ループ識別ベースのグローバル配置（ＰＡＩＬＩＧＰ）という名前の第３の手法が提供される。この新しい手法は、以下の３つのステップからなる。
・第１に、内部ループは体系的に識別されることが必要である。
・第２に、内部ループは、実行時ホットスポットを正確に反映するために、実行プロファイルと組み合わされることが必要である。
・最後に、キャッシュスロットは、谷を明らかにするために応じてスコアが決定される。
第１のステップでは、ＰｏｓｔｇｒｅＳＱＬの実行可能コードからのクエリ計画演算子関連関数全てが特定され、それらのアドレスおよび長さが記録される。クエリ準備時に、キャッシュスロット参照を追跡するために、１２８の数の配列が構築される。各演算子ノードに組み込まれた概算濃度は、演算子が実行される回数として利用される。したがって、演算子がいくつかの特定のキャッシュスロットにマッピングされるたびに、ヒストグラム内の対応するキャッシュスロットの値は、概算された濃度の値だけ増分される。クエリ計画が生成された後、ヒストグラムが完全に構築され、このヒストグラムに基づいて谷を識別する。
静的および動的両方の解析を組み合わせる、ＰＡＩＬＩＧＰ配置最適化を使用すると、クエリ６の評価中のＩ１キャッシュミスはほぼ７Ｍまでさらに削減される。Ｉ１キャッシュミスレートはこれで、わずかに０．１％を超える。実行時間は、Ｉ１キャッシュミスレートが１％であった元の実行時間より１５％改善される。非常に複雑なクエリを評価する際に関与するさらに多くのビーでは、命令キャッシュミスレートは急速に増大する可能性があり、したがって、ビー配置最適化戦略は、実行時性能を向上する際に非常に重要になる。
要約すると、ビー配置を最適化するために、３つの手法が提供される。これら３つの手法は、ＴＰＣ−Ｈベンチマークからクエリ６を評価することによって比較された。不用意なビー配置では、クエリ６を評価するＩ１キャッシュミスレートは１％だった。呼び出し元の隣のローカル配置では、Ｉ１キャッシュミスレートは０．４％に削減された。グローバル関数スコアベース配置は、Ｉ１キャッシュミスレートを０．３％に削減した。最後に、プロファイル解析および内部ループ識別ベースのグローバル配置は、Ｉ１キャッシュミスレートをわずか０．１％に削減した。一般に、ＰＡＩＬＩＧＰ手法が最も効果的であると考えられ、最初の２つの手法に存在する欠点を回避する。
プロファイル解析および内部ループ識別ベースのグローバル配置の擬似コードを以下に提供する。
ＣｏｍｐｕｔｅＨｏｔＳｐｏｔＨｉｓｔｏｇｒａｍ（ｈｏｔｓｐｏｔ＿ｆｕｎｃｔｉｏｎｓ）
ｈｉｓｔｏｇｒａｍ＝ＮＩＬ
ｆｏｒｅａｃｈ ｃａｃｈｅ＿ｌｉｎｅ ｉｎ ｃａｃｈｅ＿ｌｉｎｅｓ
ｄｏ
ｈｉｓｔｏｇｒａｍ［ｃａｃｈｅ＿ｌｉｎｅ］＝０
ｅｎｄ ｆｏｒ
ｆｏｒｅａｃｈ ｆｕｎｃｔｉｏｎ ｉｎ ｈｏｔｓｐｏｔ＿ｆｕｎｃｔｉｏｎｓ
ｄｏ
ｈｉｓｔｏｇｒａｍ［ＢｅｇｉｎＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）．．ＥｎｄＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）］＝
ｈｉｓｔｏｇｒａｍ［ＢｅｇｉｎＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）．．ＥｎｄＡｄｄｒｅｓｓ（ｆｕｎｃｔｉｏｎ）］＋１；
ｅｎｄ ｆｏｒ
ｒｅｔｕｒｎ ｈｉｓｔｏｇｒａｍ
ＰｌａｃｅＢｅｅｓ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ，ｐｒｏｆｉｌｅ＿ｒｅｓｕｌｔ）
ｂｅｅｓ＿ｔｏ＿ｐｌａｃｅ＝ＩｎｓｔａｎｔｉａｔｅＢｅｅｓ（）；
ｑｕｅｒｙ＿ｌｏｏｐ＝ＥｘｔｒａｃｔＱｕｅｒｙＬｏｏｐ（ｅｘｅｃｕｔａｂｌｅ＿ｆｉｌｅ）
ｒｕｎｔｉｍｅ＿ｈｏｔｓｐｏｔ＿ｆｕｎｃｔｉｏｎｓ＝
ＩｄｅｎｔｉｆｙＨｏｔｓｐｏｔＦｕｎｃｔｉｏｎｓ（ｑｕｅｒｙ＿ｌｏｏｐ，ｐｒｏｆｉｌｅ＿ｒｅｓｕｌｔ）；
ｈｉｓｔｏｇｒａｍ＝ＣｏｍｐｕｔｅＨｏｔＳｐｏｔＨｉｓｔｏｇｒａｍ（ｒｕｎｔｉｍｅ＿ｈｏｔｓｐｏｔ＿ｆｕｎｃｔｉｏｎｓ）；
ｆｏｒｅａｃｈ ｂｅｅ ｉｎ ｂｅｅｓ＿ｔｏ＿ｐｌａｃｅ
ｄｏ
ｃａｃｈｅ＿ｌｉｎｅ＝ＦｉｎｄＶａｌｌｅｙＣａｃｈｅＬｉｎｅ（ｈｉｓｔｏｇｒａｍ）
ｉｆ ｃａｃｈｅ＿ｌｉｎｅ ｉｓ ｖａｌｉｄ
ｔｈｅｎ
ＰｌａｃｅＢｅｅａｔＣａｃｈｅＬｉｎｅ（ｂｅｅ，ｃａｃｈｅ＿ｌｉｎｅ）
ｅｌｓｅ
ＰｌａｃｅＢｅｅａｔＣａｃｈｅＬｉｎｅ（ｂｅｅ，０）
ｅｎｄ ｉｆ
ｅｎｄ ｆｏｒ
第８項：評価
マイクロ特化は、多数の分岐を含む汎用コードを、クエリ評価ループで不変量であると識別された値に依存する、高度にカスタマイズされたコードに置換する。その結果、各ビー起動でより少ない命令が起動され、全体で合計されると、ループの周囲でしばしば何百回であり、性能の顕著な向上となり得る。さらに、ビーを実行することによって導入される命令キャッシュ圧力を抑制する手法が前項で考察された。
この項では、事例研究で検討されたような単純な選択クエリ、ＴＰＣ−Ｈベンチマーク［１３］のＯＬＡＰ様式クエリおよび高性能の一括ロード、ならびにＴＰＣ−Ｃベンチマーク［１２］のＯＬＴＰ様式クエリおよび修正という、多くの状況に対して、マイクロ特化の性能影響に関する実証的研究が提供される。
ＴＰＣ−Ｈのデータセットを生成するために、ＤＢＧＥＮツールキット［１３］が利用された。データ生成のスケールファクタは、１に設定され、データのサイズは１ＧＢになる。スケールファクタが５および１０に設定された性能研究も実施され、それぞれ、５ＧＢデータベースおよび１０ＧＢデータベースを生じる。ＴＰＣ−Ｃの場合、ＢＥＮＣＨＭＡＲＫＳＱＬ−２．３．２ツールキット［９］が使用された。ウェアハウスパラメータの数は、初期のデータセットを作成した際、１０に設定された。このため、作業負荷をシミュレーションするために合計で１００台の端末が使用された（ＴＰＣ−Ｃの資料に指定されるようにウェアハウスあたり１０台）。第５項のリスト６に示されるように、ＴＰＣ−Ｈ関係におけるいくつかの低濃度属性を識別するために、ＤＤＬ注釈も追加された。スケールファクタ、ＤＤＬ注釈、およびウェアハウスの数を指定した以外、実験データセットを準備するために、ＴＰＣ−ＣおよびＴＰＣ−Ｈツールキットで使用される他のパラメータには変更は全く行われなかった。
実験の全ては、４つのコアを含む、２．８ＧＨｚ Ｉｎｔｅｌ ｉ７ ８６０ＣＰＵを装備したマシン上で実施された。各コアは、３２ＫＢの命令（Ｉ１）および３２ＫＢのデータキャッシュからなる、６４ＫＢ レベル１（Ｌ１）キャッシュを有する。ＣＰＵは、２５６ＫＢの未統一レベル２（Ｌ２）キャッシュでも構成される。プロトタイプ実装は、ＰｏｓｔｇｒｅＳＱＬバージョン８．４．２を使用し、デフォルトのビルドパラメータを用いて（具体的には、最適化レベルが−Ｏ２である）ＧＣＣバージョン４．４．３を使用してコンパイルされた。第７．３項で導入したＰＡＩＬＩＧＰ配置が、ビーを配置するために利用された。
８．１ ＴＰＣ−Ｈベンチマーク
まず、ＴＰＣ−Ｈベンチマークは、ビー有効のＰｏｓｔｇｒｅＳＱＬと普通のＤＢＭＳの性能を比較するために利用される。ＴＰＣ−Ｈベンチマークは、商業用データウェアハウスに類似するデータベースを作成する。ベンチマークで使用されたクエリは、複雑な解析クエリである。このような作業負荷は、集中的な結合、述語評価、および集約を特徴とし、大量のディスクＩ／Ｏおよびカタログ参照が関与する。一括ロードの研究において、同じ関係を投入する際の実行時間の向上が数量化された。
ＴＰＣ−Ｈベンチマークは、８つの関係を含む。２つの関連ビー（ｓｕｐｐｌｉｅｒおよびｐａｒｔｓｕｐｐ）および８５のタプルビー（以下の第８．１．５項で記載するように、他の６つの関連のため）の合計サイズは２１ＫＢである。クエリビー全てのサイズは５９ＫＢである。この追加されたコードは、１６ＭＢである、ビーが有効なＰｏｓｔｇｒｅＳＱＬの実行可能ファイルのサイズのわずかほんの一部（０．５％）と計測される。第３．４項に記載のように、ＨＲＥは、ビーが有効なＰｏｓｔｇｒｅＳＱＬにコードを追加する。また、実行時に作成されるためにソースコードが必要である、関係およびタプルビーを作成する関数は、ビーが有効なＰｏｓｔｇｒｅＳＱＬにコード量を追加する。ＨＲＥは、約２２５ＫＢのオブジェクトコードから構成されることが見出された。関係およびタプルビーの作成関数は、わずか２ＫＢを超えるバイナリコードからなる。この合計は、３００ＫＢ未満である。この追加のコードは、実行時に、（１６ＭＢのうち）約２％未満のフットプリントしかＰｏｓｔｇｒｅＳＱＬに導入しない。
ビーが有効なＰｏｓｔｇｒｅＳＱＬのサイズ（静的）は、普通のＰｏｓｔｇｒｅＳＱＬより大きいが、各クエリの評価中、これらのビーの一部しか起動されない。より小さいビールーチンが、実行時のメモリにより大きいフットプリントを有するＤＢＭＳの汎用コードを代用するため、実行時の命令キャッシュ性能は実際に向上する。
８．１．１ スケールファクタ＝１のクエリ評価性能
ＴＰＣ−Ｈに指定された２２のクエリ全てが普通およびビーが有効なＰｏｓｔｇｒｅＳＱＬの両方で評価された。実行時間は、ウォームキャッシュのシナリオで、ウォールクロック時間として測定された。ウォームキャッシュのシナリオは、最初に、ＣＰＵ性能を研究するために対処される。メモリ内のデータを維持することで、ディスクＩ／Ｏリクエストを排除した。次いで、コールドキャッシュシナリオが検討される。
各クエリは、１２回実行された。最大および最低の測定値は、外れ値と考え、したがって排除された。各クエリの実行時間測定値は、残りの１０回の実行の平均として考慮された。２２のクエリの各々の残りの１０回の実行の標準偏差は、１％未満であることが見出された。
結果の有効性および再現性を保証するために、これらの２２のクエリを評価する際に、普通およびビーが有効なＰｏｓｔｇｒｅＳＱＬの両方が事実同じクエリ計画を使用していることを保証しようと試みた。２つのＤＢＭＳが必ず同じ計画を選択することを保証することは、特に、下位の関係がマイクロ特化を通じて２つのＤＢＭＳの下で、関係サイズ、タプルサイズ、および関係によって占有されるページ数等、異なる特徴を有するため、困難であった。しかしながら、ｐｏｓｔｇｒｅｓｑｌ．ｃｏｎｆファイルのｄｅｆａｕｌｔ＿ｓｔａｔｉｓｔｉｃｓ＿ｔａｒｇｅｔパラメータを１０００に設定することによって（１００がデフォルト）、クエリのうち２１が２つのＤＢＭＳで同じ計画を使用していることを保証することが可能であった。異なる計画を用いる唯一のクエリはクエリ２１であった。
図１１は、バー１−２２として示される、ウォームキャッシュで２２のクエリの各々のパーセント性能向上を示す。２つの要約測定値が含まれ、斜線バーとして示される、Ａｖｇ１ ３４４およびＡｖｇ２ ３４６と呼ばれる。Ａｖｇ１ ３４４は、各クエリが同等に加重されるように、２２のクエリ全体の平均パーセント向上によって計算される。Ａｖｇ２ ３４６は、クエリ評価時間全ての合計を比較することによって計算される。クエリ１７およびクエリ２０は、残りは１〜２３秒かかったのに対し、それぞれ１時間および２時間という、はるかに長い時間が終了にかかったことから、Ａｖｇ２ ３４６は、これらの２つのクエリに非常に偏向する。向上の範囲は、１．４％〜３２．８％で、Ａｖｇ１ ３４４およびＡｖｇ２ ３４６はそれぞれ、１２．４％および２３．７％である。この実験では、タプルビー、関係ビー、およびクエリビーが有効に設定され、ＧＣＬ、ＥＶＰ、およびＥＶＪビールーチンが関与する（これらのビールーチンの検討については、第２項および第６項を参照）。図１１に示されるように、Ａｖｇ１ ３４４およびＡｖｇ２ ３４６はどちらも大きく、わずかなビールーチンを使用してビーが有効なＰｏｓｔｇｒｅＳＱＬで達成された性能向上が顕著であることを示す。
図１２は、各クエリで実行された命令数の改善を表す。動的命令の削減カウントは、０．５％〜４１％の範囲で、Ａｖｇ１ ３５０およびＡｖｇ２ ３５２はそれぞれ、１４．７％および５．７％である。ＣＡＬＬＧＲＩＮＤでプロファイリングすると、プログラム実行は通常、終了するまで、約２００回もっと長くかかることに注意されたい。このため、プロファイルデータは、ｑ１７およびｑ２０では収集されず、このため、プロファイルに関する結果は、これらの２つのクエリでは省略された。（これは、本項に示されたＴＰＣ−Ｈクエリに関する他のプロファイルベースの研究で同様である。）このプロットは、実行時間の向上は、実行された命令の削減と高い相関関係があることを示し、マイクロ特化のメリットが、削減された命令実行から生まれることをさらに強調する。
タプルビーによって達成されたＩ／Ｏ向上を確実にするために、ディスクＩ／Ｏ時間が実行時間全体の主要な構成要素になる、コールドキャッシュで２２のクエリの実行時間が検証された。図１３は、コールドキャッシュでの実行時間向上を示す。向上範囲は、０．６％〜３２．８％で、Ａｖｇ１ ３５４は１２．９％、Ａｖｇ２ ３５６は２２．３％である。この図と図１１の顕著な違いは、ｑ９の性能がコールドキャッシュで顕著に向上している点である。その理由は、ｑ９が６つの関連スキャンを有することである。タプルビーは、ｌｉｎｅｉｔｅｍ、ｏｒｄｅｒｓ、ｐａｒｔ、およびｎａｔｉｏｎ関係で有効になっている。このため、これらの関係をスキャンすると、特に、最初の２つでは、属性値特化から顕著なメリットが得られ（ディスク読み出しの回数を削減）、このため、コールドキャッシュで１７．４％の向上が達成される。
８．１．２ スケールファクタ＝５のクエリ評価性能
より大型のデータベースでの性能利点をさらに確認するため、ＴＰＣ−Ｈベンチマークのスケールファクタを５に増加した。このより大きいスケールファクタでは、Ｐｏｓｔｇｒｅ−ＳＱＬのデフォルト構成は十分ではない。具体的には、デフォルト構成では、ｓｈａｒｅｄ＿ｂｕｆｆｅｒパラメータおよびｗｏｒｋ＿ｍｅｍパラメータは、それぞれ、わずか２４ＭＢおよび１ＭＢに設定される。このような小さい設定は、クエリ評価中の頻繁なディスク読み出しおよび書き込みを招く。ｓｈａｒｅｄ＿ｂｕｆｆｅｒパラメータは、ＰｏｓｔｇｒｅＳＱＬによって利用されるバッファプールのサイズを表す。ｓｈａｒｅｄ＿ｂｕｆｆｅｒは、メインメモリのサイズの最大４０％まで、可能な限り大きく構成されるべきであることが示唆される［１１］。ＴＰＣ−Ｈベンチマークの関係のうちの５つのサイズは、２５６ＭＢ以下である。他の３つの関係は、それぞれ約７００ＭＢ、９００ＭＢ、および４ＧＢである。ｓｈａｒｅｄ＿ｂｕｆｆｅｒは、２５６ＭＢに設定され、わずかな関係がメモリにキャッシュされることを可能にする一方、他の関係がディスクから読み出されるように強制する。加えて、ｗｏｒｋ＿ｍｅｍパラメータの場合、ＰｏｓｔｇｒｅＳＱＬの参考マニュアルでは、このパラメータは、「一時ディスクファイルに切り替える前に、内部のソート操作およびハッシュテーブルによって使用されるメモリ量を指定する」と記載されている。［１１］このパラメータは、クエリ評価が大型の関係をハッシュおよびソートする間、これらの操作全体がメモリ内で実行されるのではなく、相当量のＩ／Ｏをまだ要求するので、１００ＭＢに設定された。
ＴＰＣ−Ｈクエリ（クエリ１７およびクエリ２０を除く）は全て、ウォームキャッシュで両方のＤＢＭＳ上で実行された。ビーが有効なＰｏｓｔｇｒｅＳＱＬによって達成された性能向上は、図１４に報告される。この図によって示されるように、スケールファクタが５の場合に観察されたＡｖｇ１ ３６０およびＡｖｇ２ ３６２の性能向上は、図１１に報告されたスケールファクタが１の場合に観察された性能向上と（わずかなパーセントポイント分高いものの）同程度である。クエリ１７およびクエリ２０がないため、図１４に示されるＡｖｇ２ ３６２は、図１１に示されるＡｖｇ２よりも低い。
性能ゲインの発生源を究明するため、ＴＰＣ−Ｈクエリを評価中に実行プロファイルが収集された。ビーが有効なＰｏｓｔｇｒｅＳＱＬおよび普通のＰｏｓｔｇｒｅＳＱＬを比較して、実行された命令数における向上は、図１５に示される。スケールファクタが１の場合に収集された結果に類似して、クエリ評価時間の向上および実行された命令数の削減の間に強力な相関関係が観察される。スケールファクタを５に設定すると、達成されたクエリ評価時間の向上は、最高３６％である。ＴＰＣ−Ｈクエリ全体の平均向上は、Ａｖｇ１ ３６４およびＡｖｇ２ ３６６で、それぞれ、１４％および１０％である。
８．１．３ スケールファクタ＝１０のクエリ評価性能
ここで、スケールファクタを１０に設定して生成される、さらに大型のデータセットの実験に注目を移す。この場合、３つの関係のサイズは２５６ＭＢ以下である。他の関係は、３００ＭＢ〜１０ＧＢまでばらつきがあり、３つの関係はサイズが１ＧＢを超える。この大型データセットに適切に合わせてＰｏｓｔｇｒｅＳＱＬを構成するために、クエリ評価中、特にソートおよびハッシュ中に、非常に頻繁なディスクＩ／Ｏを削減することができるように、実験用マシンは８ＧＢのメインメモリを有することから、ｓｈａｒｅｄ＿ｂｕｆｆｅｒは最大に示唆される３．２ＧＢに設定された。ｗｏｒｋ＿ｍｅｍパラメータは、２つの最大の関係が、ディスクベースの手法でソートおよびハッシュされるために必要である、２ＧＢに設定された。
ＴＰＣ−Ｈクエリが実行され、ビーが有効なＰｏｓｔｇｒｅＳＱＬによって達成された向上を図１６に示す（Ａｖｇ１ ３６８およびＡｖｇ２ ３７０を参照）。
スケールファクタが１および５であった場合とは異なり、クエリ評価の向上は、実行された命令数の削減ともはや関連しないことが、図１７に報告される（Ａｖｇ１ ３７２およびＡｖｇ２ ３７４を参照）。これは、この大型データセットでは、ＰｏｓｔｇｒｅＳＱＬは大量のバッファプールを有するように構成されたが、ディスクＩ／Ｏが圧倒的なボトルネックになるためである。クエリ６を例として説明する。図１７は、実行された命令の削減が４０％を超えることを示唆する。しかしながら、クエリ評価時間の向上はわずか約６％である。
クエリ６のクエリ評価時間は、両方のＤＢＭＳ上で調査された。普通のＰｏｓｔｇｒｅＳＱＬでは、クエリ評価時間合計は９８秒であることが見出された。ＣＰＵ時間は１８秒であった。
時間の約８２％はディスクＩ／Ｏに費やされた。ビーが有効なＰｏｓｔｇｒｅＳＱＬでは、ＣＰＵ時間は１２秒に短縮し、実行された命令の４０％削減と一貫する。しかし、ディスクＩ／Ｏはそれでも、９０秒のクエリ評価時間合計の最高８７％を占める。このため、全体的な向上が相当な影響を受けた。
実験マシンが限定されたメモリを有することから、多様なメモリ構成による性能の向上は、さらに調査することができなかった。９６ＧＢのメモリで構成される別のマシンがこの大量のデータセットの性能実験に利用された。
まず、両方のＰｏｓｔｇｒｅＳＱＬ ＤＢＭＳは大量のメモリで構成された。具体的には、ｓｈａｒｅｄ＿ｂｕｆｆｅｒパラメータは、最大推奨サイズ３２ＧＢ（９６ＧＢ×４０％）に設定された。ｗｏｒｋ＿ｍｅｍパラメータは８ＧＢに設定され、８つのＴＰＣ−Ｈ関係のうちの７つのハッシュおよびソートがメインメモリ内部で動作することを可能にする。しかしながら、１０ＧＢを超えるｌｉｎｅｉｔｅｍ関係は、依然として、ディスクベースのソートおよびハッシュが必要である。
クエリ評価時間の向上および実行された命令の削減は、それぞれ、図１８（Ａｖｇ１ ３７６およびＡｖｇ２ ３７８を参照）および図１９（Ａｖｇ１ ３８０およびＡｖｇ２
３８２を参照）に示される。大量のメモリを構成したことで、クエリ評価時間の向上はここでも、実行された命令の削減と一貫する。さらに、スケールファクタが１０の場合に達成された性能向上は、スケールファクタが５の場合に達成された向上と同程度である。
クエリ評価時間向上に対するＩ／Ｏ効果をさらに理解するために、ＰｏｓｔｇｒｅＳＱＬのメモリ関連構成を変動させることによって、クエリ７が詳細に研究された。この複雑なクエリは、６つの関係の結合を含む。また、このクエリは、５つの述語、１つの集約関数、および演算子による順番が関与する。
ｗｏｒｋ＿ｍｅｍパラメータは、ディスクベースのハッシュおよびソートによって生じたＩ／Ｏオーバーヘッドと、マイクロ特化によって達成されたクエリ評価時間の向上との間の関係を調査するために解析された。図２０は、ｗｏｒｋ＿ｍｅｍパラメータの多様な値で、ビーが有効なＰｏｓｔｇｒｅＳＱＬによって達成されたクエリ評価時間の向上を示す。ｗｏｒｋ＿ｍｅｍの値が増加すると、クエリ評価時間の向上も増加する。この特定のクエリでは、述語は、ｌｉｎｅｉｔｅｍ関係からプロジェクトされたタプルの数を顕著に削減するので、得られる中間関係の結合は、相当量のメモリを必要としない。したがって、ｗｏｒｋ＿ｍｅｍパラメータを１２８ＭＢより大きく設定すると、両方のバージョンのＰｏｓｔｇｒｅＳＱＬの実際のクエリ評価時間は、変動しない。このため、ビーが有効なＰｏｓｔｇｒｅＳＱＬによって達成されるクエリ評価時間の向上は、２０％で安定する。
この研究は、クエリ評価中に、ソートおよびハッシュのために追加のＩ／Ｏオーバーヘッドが関与する場合であっても、マイクロ特化は、相当な性能向上を達成することが可能であることを示す。
第２の研究では、ｗｏｒｋ＿ｍｅｍパラメータの値は固定されたが、ｓｈａｒｅｄ＿ｂｕｆｆｅｒパラメータが変動された。これは、関係の読み出しのＩ／Ｏオーバーヘッドと、マイクロ特化によって達成される性能向上との間の関連性を研究するためである。この研究では、クエリ７がコールドキャッシュで評価されたことに注意されたい。これは、実験用マシンが９６ＧＢのメインメモリで構成され、ＴＰＣ−Ｈ関係全てをキャッシュできるためである。したがって、関係がディスクから読み出されることを要求するために、コールドキャッシュが利用された。また、オペレーティングシステムキャッシュだけがクリアされたことにも注意されたい。ＰｏｓｔｇｒｅＳＱＬによって管理される共有メモリはクリアされない。共有メモリは通常、関係タプル、中間クエリデータ、およびＤＢＭＳによって利用される多様な他のデータによって占有される。ｓｈａｒｅｄ＿ｂｕｆｆｅｒパラメータを１ＧＢに設定することによって、クエリ評価中にほとんどの関係がディスクから読み出されることを要求する、ＰｏｓｔｇｒｅＳＱＬによって最大１ＧＢのデータをキャッシュすることが可能になる。一方、ｓｈａｒｅｄ＿ｂｕｆｆｅｒを１６ＧＢに設定すると、クエリ評価中により少ないＩ／Ｏが要求され、オペレーティングシステムキャッシュはクリアされなくても、ＴＰＣ−Ｈ関係の部分が共有メモリにキャッシュされ得る。ｓｈａｒｅｄ＿ｂｕｆｆｅｒが６４ＧＢに構成されると、ベンチマークの関係全てはメモリ内に十分にキャッシュすることができる。
ＤＢＭＳにより多くのメモリが構成されると、クエリ評価により少ないＩ／Ｏが要求され、したがって、ビーが有効なＰｏｓｔｇｒｅＳＱＬは、より顕著な性能向上を達成すべきであることが予想される。すなわち、性能向上は、メモリを増設することによって、単調に増大すべきである。しかし、図２１に示されるように、現実は、この予想よりも複雑である。
図２１には、３つの興味深い現象が示される。まず、８Ｇでは、クエリ評価時間の向上に約１５％〜２０％を超えるジャンプが存在する。第２に、１６Ｇでは、クエリ評価時間の向上は約１０％減少し、より少ないメモリが構成された場合よりもさらに低い。最後に、６４Ｇでは、クエリ評価時間の向上は２２％以上急激に上昇する。
これらの現象を理解するために、さらなる実行統計が調査された。表８．１において、ｎｕｍ．ｂｌｏｃｋｓ（普通）およびｎｕｍ．ｂｌｏｃｋｓ（ビー）という名前の列は、多様なメモリ構成で、それぞれ、普通のＰｏｓｔｇｒｅＳＱＬおよびビーが有効なＰｏｓｔｇｒｅＳＱＬで、クエリ７の評価中のディスクから読み出されるブロック数を示す。ｓｈａｒｅｄ＿ｂｕｆｆｅｒが１Ｇで構成される場合、ビーが有効なＰｏｓｔｇｒｅＳＱＬは、約１０％少ないディスクブロックを読み出す。これは、この場合、ｌｉｎｅｉｔｅｍ関係でタプルビーを利用することによって、この関係のサイズが１０％削減されるためである。追加の詳細は第８．１．５項に記載する。ｓｈａｒｅｄ＿ｂｕｆｆｅｒに８Ｇが構成されると、ビーが有効なＰｏｓｔｇｒｅＳＱＬによって読み出されるディスクブロック数に顕著な減少が観察される。いうまでもなく、このような減少は、ｓｈａｒｅｄ＿ｂｕｆｆｅｒが８Ｇの場合の普通のＰｏｓｔｇｒｅＳＱＬでは全く観察されない。これは、ここでも、ビーが有効なＰｏｓｔｇｒｅＳＱＬによって作成されるＴＰＣ−Ｈ関係は、一般に、普通のＤＢＭＳによって作成される関係より小さいためである。８Ｇは、この特定のクエリに対して、ビーが有効なＰｏｓｔｇｒｅＳＱＬの下でより多くの関係がメモリ内に適合可能な点であり、普通のＤＢＭＳは、さらに多くの関係がディスクから読み出されることを要求する。
第２の現象に関して、１６Ｇで、普通のＰｏｓｔｇｒｅＳＱＬがより多くの関係をキャッシュできることを観察した。一方、ビーが有効なＤＢＭＳは、ｓｈａｒｅｄ＿ｂｕｆｆｅｒに８Ｇが構成されているため、同じ量のディスクブロックが読み出されることを要求する。表８．１において、Ｉ／Ｏパーセント（普通）およびＩ／Ｏパーセント（ビー）の列は、それぞれ、普通のＰｏｓｔｇｒｅＳＱＬおよびビーが有効なＤＢＭＳの全体的なクエリ評価時間におけるパーセントＩ／Ｏ時間を示す。１６Ｇの行の値によって示されるように、Ｉ／Ｏは、普通のＰｏｓｔｇｒｅＳＱＬによって、クエリ７を評価するための時間全体の５５％を占める。
ビーが有効なＰｏｓｔｇｒｅＳＱＬの場合、クエリ評価時間のうちの５０％がＩ／Ｏによって占められる。これらの２つの値は、８Ｇの列に示される値と同程度である。したがって、ｓｈａｒｅｄ＿ｂｕｆｆｅｒが８Ｇから１６Ｇになると、クエリ評価中に読み出されるディスクブロック数の減少が、ビーが有効なＰｏｓｔｇｒｅＳＱＬによって達成される全体的な性能向上の減少となる。
最後に、６４Ｇの列に示されるように、普通のＰｏｓｔｇｒｅＳＱＬおよびビーが有効なＰｏｓｔｇｒｅＳＱＬのどちらも、クエリ評価中にディスクブロックがロードされることを要求しない。このため、図２１に示されるように、２２％である性能向上は、圧倒的にＣＰＵ時間によって占められ、１００％近くである。
要約すると、マイクロ特化は、Ｉ／Ｏ時間およびＣＰＵ時間両方の向上を同時に達成することが可能である。全体的なクエリ評価性能向上は、さまざまな因子によって決定される。例えば、ＤＢＭＳに構成されたバッファキャッシュのサイズは、クエリ評価中に要求されるディスクＩ／Ｏの量を決定する。小さいキャッシュは、全体的なクエリ評価時間内の高パーセントのＩ／Ｏ時間となる。このような場合、マイクロ特化によって達成される性能向上は大部分がタプルビーに起因する。一方、大量のバッファは、最小のＩ／Ｏを保証し、したがって、性能向上は、クエリ評価中に実行される命令数の削減と一貫する。バッファのより現実的な構成は、Ｉ／Ｏ時間の向上およびＣＰＵ時間の向上を平均化する。例として、ソリッドステートドライブ等、より高速のディスクドライブが採用される場合、全体的な評価時間におけるＩ／Ｏ時間のパーセントは、効果的に削減することができ、より顕著なＣＰＵ時間の向上、したがってより大きい全体的な性能向上を示す。概して、マイクロ特化は、ＤＢＭＳバッファの多様な構成によって顕著な向上を達成することができる。
８．１．４ 複数のビールーチンの影響
各クエリの性能向上は、起動される追加のビー各々によって増加する。第２項において、関係ビーのＧＣＬルーチンが９％の向上を達成したことを思い出されたい。基本的な質問は、ビーをさらに追加することによって、さらにどの程度の向上を達成することができるのか、である。より重要な点として、多数のビーは相互に悪影響を与えるのだろうか。
多様なビールーチンを有効にする影響が検証された。結果は、図２２に要約される。この図によって示されるように、ＧＣＬルーチンだけの平均向上は、Ａｖｇ１ ３８６では７．６％およびＡｖｇ２ ３９０では１３．７％である。ＥＶＰルーチンを有効にすることによって、Ａｖｇ向上は、１１．５％（Ａｖｇ１）および２３．４％（Ａｖｇ２）まで到達する。
一般に、２２のクエリの中で、４つのクラスの向上が観察される。最初のクラスは、クエリ２によって示され、追加のビールーチンが有効になるたびに、性能が大幅に向上する。これは、このようなクエリは、多数の結合および述語評価からなり、このために、クエリビーが性能に顕著な利益を与えることができるためである。第２のクラスは、クエリ６によって示され、述語評価ビールーチンを有効にすると、性能が大幅に向上するが、評価結合ビールーチンを有効にしても向上しない。これは、クエリ６が結合を含まない４つの述語からなるためである。第３のクラスは、クエリ１２によって示され、関係およびタプルビーは、性能向上に対する主な寄与因子であり、クエリビーはより低い性能影響を有する。これは、クエリ１２がＴＰＣ−Ｈベンチマークで最大の関係のうちの２つを読み出すという事実に起因する。わずかな述語および単一の結合だけが関与するため、全体的な性能向上は、これらの２つの関係からフェッチされたタプル全ての必要な属性値を抽出する、タプルビーによって寄与される。
最後に、第４のクラスは、クエリ１によって示され、全体的な向上は、上述のクラスよりはるかに低い。これは、これらのクエリでは、マイクロ特化が、関与する特定の動作にまだ利益を与えていないためである。例えば、クエリ１は、複雑な集約演算からなり、これは、マイクロ特化によってまだ特化されていない。クエリ９およびクエリ１６について、両方のクエリに含まれる述語を評価中に実行される、正規表現のマッチングは、２つのクエリの評価中のほとんどの時間を占める。正規表現のマッチングを実施するコードは、ここでも、特化されていない。さらに、クエリ１８は、タプルのソートを要求する。タプルソートコードは、特化されておらず、実行時にクエリ評価時間の大部分を占める。これらの特定のクエリは、クエリ評価中にマイクロ特化をどこで適用するかについて、さらに調査する機会を与えてくれる。
この最後のクラスで、クエリ１１は、マイクロ特化がこのクエリに対して限定された性能利点を有することも示す。これは、クエリ１１は、３つの非常に小さい関係にアクセスするためである。これらの関係のうちの２つは、タプルビーを有さないが、関係ビーを有する。第３の関係はタプルビーを有するが、この特定の関係においては、２５のタプルのみが存在する。このため、達成することができる全体的な性能利点は、これらの関係のサイズによって限定される。この特定のクエリは、第５．５項および６．６項に示されたマイクロ特化の利点についての検討を実際にサポートする。
クエリ３およびクエリ４の場合、ＥＶＪルーチンを有効にすることで、性能向上にわずかな低下を示すことにも注意されたい。これらのクエリの実行プロファイルが研究され、ＥＶＪルーチンを有効にすることによって、実行された命令の数がわずかに減少することが見出された。さらに、命令キャッシュミスも減少する。このため、性能向上におけるこのようなわずかな低下は、実行時間測定に存在する変動によってのみ、正当に説明することができる。
マイクロ特化手法が繰り返し適用できることが暗示される。マイクロ特化を適用する場所が多くなると、ＤＢＭＳが達成することができる効率が向上する。増分性能達成というこの特性は、「ビー加法性」と呼ばれる。
ＤＢＭＳのほとんどの性能最適化は、クエリまたは修正のクラスに利点があるが、他を低速化させる。たとえば、Ｂ＋ツリーインデックスは、結合の効率を高めるが、更新を低速化させる。ビールーチンは、利点のみであるという優れた特性を有する（修正中のタプルビーのインスタンス化およびビーによって追加されるキャッシュ圧力という２つの警告があるが、それぞれ、第８．１．５項および第７項に記載する）理由は、ビールーチンがクエリによって使用される場合、そのクエリの性能がいずれの場合も影響を受けないからである。一方、ビールーチンがクエリによって使用される場合、特に、ビールーチンがクエリ評価ループ内で実行することから、クエリの性能は顕著に向上し得る。図１１および図２２はどちらも性能向上の間に差を示すことに注意されたい。例えば、ｑ１、ｑ９、ｑ１６、およびｑ１８は全て、比較的低い向上を経験する。理由は、これらのクエリは全て、実装にまだマイクロ特化されていない、複雑な集約演算、サブクエリ評価、ならびに複雑な正規表現によるマッチングを有するためである。これらの向上が低いクエリは、集約、およびおそらくサブクエリ評価に対して、マイクロ特化を適用するための他の機会を示す。
８．１．５ 一括ロード
懸念は、新しく挿入されたタプルから特化された属性値が、新しいタプルビーが必要かを判定するために確認されることが必要であるという点で、関係を投入する等、修正中のタプルビーインスタンス化が高価なことがあるということである。さらに、新しいビーが作成されると、このビーを記憶するために、新しいメモリ空間が割り当てられることが必要である。この第２の警告による性能の影響の可能性を解明するために、ＴＰＣ−Ｈベンチマークの関係全てで一括ロードが実施された。表８．２は、スケールファクタが１の場合のこれらの関係のいくつかの特徴をまとめ、表８．３は、スケールファクタが１０の場合のＴＰＣ−Ｈ関係の特徴をまとめる。関係およびタプルビーの数、ならびにそれらのサイズはこれらの２つのデータセットで同じままであることに注意されたい。したがって、関連列は表８．３から削除された。
ビーが有効なＰｏｓｔｇｒｅＳＱＬの一括ロード性能は、普通のバージョンと比較された。一括ロードではクエリ評価が実施されないため、ＳＣＬビールーチンだけが関与する。図２３は、各関係に対して、ロード時間の高速化を示す。ＴＰＣ−Ｈベンチマークにおいて、ｒｅｇｉｏｎ４００およびｎａｔｉｏｎ４０２関係は、各々、２つのディスクページだけを占有し、２つの関係をロードする性能影響を測定不可能であるように非常に小さくする。したがって、各関係に対して、１Ｍ行を含むデータファイルが作成された。図２３に示された、これらの２つの関係をロードする性能は、これらの２つの関係各々に１Ｍ行を投入することに基づく。残りの測定値（ｐａｒｔ４０４、ｃｕｓｔｏｍｅｒ４０６、ｏｒｄｅｒｓ４０８、およびｌｉｎｅｉｔｅｍ４１０）は、元のスキーマおよびデータに準じる。これらの性能向上は、スケールファクタが１０の場合とほぼ同じであるべきで、一括ロード中に達成された向上は、Ｉ／Ｏの削減と強力に相関する。このような相関のさらなる証拠を図２４に示す。
タプルビーを利用しないｓｕｐｐｌｉｅｒおよびｐａｒｔｓｕｐｐ関係を一括ロードするために、ＳＣＬという名前の、タプル構築関係ビールーチンは、達成された性能向上のほとんどに寄与した。これらの２つの関係では、タプルビーが全く存在しないようにディスクスペースが削除されないという事実に起因して、残りの前述の関係と比較して、向上が低い。
図２４は、関係４００、４０２、４０４、４０６、４０８、および４１０の各々に対して、属性特化によって導入されたディスク空間削減を示す。削減は、ＤＤＬ文によって定義されたタプル長に基づいて計算された。ｏｒｄｅｒｓ関係を例として挙げると、定義によるタプルサイズは、スキーマ定義によって１４３バイトである。３つのハードコードされた属性の型ＣＨＡＲ（１）、ＣＨＡＲ（１５）、およびＩＮＴを、それぞれ加算して２０バイトになる。すなわち、空間削減は１４％である。
図２３に示される一括ロード性能向上は、一括ロード中のタプルビー作成のオーバーヘッドは、実際に、マイクロ特化の利点によって補償され、全体的な一括ロード性能が向上することを示唆する。
これらの２つの図は、連携して、一括ロードの性能向上は、Ｉ／Ｏ時間の向上と強力に相関することを示唆する。実行時命令の面から性能向上をさらに理解するために、ｏｒｄｅｒｓ関係を一括ロードする際の特性が研究された。普通のＰｏｓｔｇｒｅＳＱＬおよびビーが有効なＰｏｓｔｇｒｅＳＱＬの特性結果は、それぞれ、リスト１４および１５に示される。
リスト１４によって示されるように、この関係を一括ロードする際、普通のＰｏｓｔｇｒｅＳＱＬは１４８Ｂの命令を実行した。一方、ビーが有効なＰｏｓｔｇｒｅＳＱＬは、リスト１５によって示されるように、１４６Ｂの命令を実行した。前述のように、一括ロード中にタプルビーが作成される。具体的には、タプルビーの作成は、現在挿入されたタプル内の特化属性の値を（既存タプルビー内の）既存のデータセクション全てに対してチェックするオーバーヘッドを導入する。このチェックは、リスト１５に示される、ＩｎｓｅｒｔＤａｔａＳｅｃｔｉｏｎＴｏＢｅｅＣａｃｈｅ関数によって実行される。加えて、ビーが有効なＰｏｓｔｇｒｅＳＱＬ内のヒープフォームタプル関数は、１．９７Ｂ件の命令を実行する一方、普通のバージョンでは、この関数は１．６９Ｂ件の命令を実行することが見出された。このほぼ３００Ｍに近い命令の増加は、ビーが有効なＰｏｓｔｇｒｅＳＱＬ内の各タプルのビーＩＤを記憶させるコードによって導入された。これらの２つの関数は連携して、追加の１．３Ｂ件の命令を発生させたが、普通のＰｏｓｔｇｒｅＳＱＬにおいて、物理的タプルを構築するｈｅａｐ＿ｆｉｌｌ＿ｔｕｐｌｅ関数が４．６Ｂ件の命令を実行したのに対し、ビーが有効なＰｏｓｔｇｒｅＳＱＬは、リスト１５によって示されるように、代わりに、２．４Ｂの命令を実行した、ＳＣＬビールーチンを利用し、実行された命令数で２．２Ｂを超える削減を有効にし、ｏｒｄｅｒｓ関係を一括ロードするための全体的な性能はそれでも向上した。
要約すると、一括ロードにおける性能向上は、実行された命令数の削減、ならびにディスク空間の削減、このために入力時間の削減の両方の結果である。両方の利点は、関係ではなく、ビー内部の（個別の）属性値を効率的に記憶することによって、これらの値があたかもオブジェクトコードにハードコードされているかのように、タプルビールーチンによりこれらの値の直接アクセスすることができるように、属性値を特化するタプルビーを利用することによって同時に達成される。
個別の属性値がタプルビー内に記憶されることが必要な場合、必要なメモリを前もって割り当てるために、スラブ割り当て技法が採用され、したがって、タプルビー作成中の高価な小さくかつ頻繁なメモリ割り当てを回避する。新しいビーが必要であるかどうかを判定するために、ｍｅｍｃｍｐを用いて、いくつか（最大２５６）の可能な値をチェックする。図２３は、このステップが有効であることを示す。
要約すると、ビー作成は、ＤＢＭＳ動作の性能に悪影響を与えず、むしろ、単一のビールーチンであってもその利点によって性能が向上する。
８．２ ＴＰＣ−Ｃベンチマーク
ＴＰＣ−Ｃベンチマークは、スループットを中心とする。このベンチマークは、並列に実行する５つのタイプのトランザクションが関与する。スループットは、１分あたりに処理される「Ｎｅｗ−Ｏｒｄｅｒ」トランザクションの数（ｔｐｍＣ）として測定される。この研究の場合、ｔｐｍＣ値が高くなると、性能（スループット）が向上することを示すことに注意されたい。他の４つのタイプのトランザクションは、無作為なクエリおよび修正の混合を生成し、これらは合わせて、ビールーチンを集中的に起動する。
このベンチマークは９つの関係を含む。属性値の仕様に起因して、属性値は全く特化できない。このため、ＴＰＣ−Ｃベンチマークでは、関係ビーのみが有効である。関係ビー全体のサイズは２６ＫＢである。クエリビー全ては連携して、５９ＫＢの記憶容量が必要である。
実験では、ビーが有効なＰｏｓｔｇｒｅＳＱＬを普通のＤＢＭＳと比較した。各ＤＢＭＳは、自動バキュームプロセス等、実験用システムならびにＤＢＭＳによって導入された差異を削減するために１時間実行された。
マイクロ特化を用いて修正を実施すると、前者は、１分あたり１８９８トランザクションを完了したが、普通のＤＢＭＳは、１分あたり１７６０トランザクションを実行することができ、７．３％の向上で、実際に高速化した。
ＴＰＣ−ＣベンチマークのこのｔｐｍＣ測定評価基準以外に、異なるトランザクション設定でのスループットも研究された。さらに２つの極めて異なるシナリオが対処された。５つの定義されたトランザクションタイプのうち３つ、Ｎｅｗ−Ｏｒｄｅｒ、Ｐａｙｍｅｎｔ、およびＤｅｌｉｖｅｒｙは、クエリおよび修正の両方を含み、一方、Ｏｒｄｅｒ−ＳｔａｔｕｓおよびＳｔｏｃｋ−Ｌｅｖｅｌはクエリのみを含む。どちらのシナリオでも、Ｎｅｗ−Ｏｒｄｅｒトランザクションの加重は４５％に保たれた。デフォルトの設定は、Ｐａｙｍｅｎｔトランザクションの加重が４３％である、修正主体のシナリオに類似する。新しく定義されたシナリオに関して、第１は、２７％のＯｒｄｅｒ−Ｓｔａｔｕｓおよび２８％のＳｔｏｃｋ−Ｌｅｖｅｌトランザクションからなる（すなわち、クエリのみ）。第２のシナリオは、修正およびクエリ両方が等しく混合される。ＰａｙｍｅｎｔおよびＤｅｌｉｖｅｒｙトランザクションの加重は２７％であるが、他の２つのタイプのトランザクションは、連携して２８％に加重される。
第１のシナリオ、クエリのみの場合、ビーが有効なＰｏｓｔｇｒｅＳＱＬおよび普通のＤＢＭＳは、それぞれ、１分あたり３６９９および３１３５件のトランザクションを処理し、１８％の向上だった。第２のシナリオ、修正およびクエリが等しく加重される場合、ビーが有効なＰｏｓｔｇｒｅＳＱＬは、２２２０件のトランザクションを達成し、普通のバージョンは１９９８件を終了した。向上は１１．１％であった。
プロファイルの結果、修正およびクエリ両方は、タプル値を抽出するために、ｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ関数に依存することを示唆する。この関数は、ＧＣＬルーチンでマイクロ特化されるため、ＴＰＣ−Ｃベンチマークの多様なシナリオで顕著な性能向上が達成される。さらに、この作業負荷のクエリは述語が関与するため、ＥＶＰルーチンは、向上したスループット、特にクエリ中心のシナリオにも寄与した。
８．３ コンパイラ最適化との比較
クエリ評価におけるマイクロ特化の性能効果は、コンパイラ最適化を併用した場合も研究された。調査された１つの重要な質問は、コンパイル時に（ＤＢＭＳの）積極的な最適化を有効にすることが、マイクロ特化によって達成される性能向上を削減するかどうかである。すなわち、コンパイラ最適化は、マイクロ特化に対して同じ性能利点を十分に達成することができるのか、それによって、マイクロ特化が不要であることを示すだろうか？
ＴＰＣ−Ｈベンチマークのクエリ６の性能が、スケールファクタを１に構成して研究された。具体的には、普通のＰｏｓｔｇｒｅＳＱＬおよびビーが有効なＰｏｓｔｇｒｅＳＱＬの両方は、３つのオプションを用いてコンパイルされた。これらのオプションは、−Ｏ０（最適化なし）、−Ｏ１（コードサイズおよび実行時間を削減）、および−Ｏ２（空間と速度のトレードオフを要求しない最適化全て）である［７］。
表８．４に、両方のＤＢＭＳに対するクエリ６の評価時間、およびマイクロ特化によって達成される対応する性能向上をまとめた。
この表が示すように、より積極的な最適化オプションが有効になると、マイクロ特化によって達成される全体的な性能向上がわずかに減少する。しかし、向上は全て多様なコンパイラ最適化に対して顕著であり、コンパイラ最適化だけによって達成される性能向上は、マイクロ特化によって達成される利点を十分に代用することができないことを示す。
その上、さらに積極的な最適化、フィードバック駆動最適化（ＦＤＯ）が調査された。分岐条件チェックを削除する等、マイクロ特化によって実現される所定の最適化は、それぞれ、ＦＤＯおよび最新ＣＰＵによって採用される、分岐予想および命令パイプラインによって同等に達成することができると論じるかもしれない。理想的なＦＤＯ最適化によってＰｏｓｔｇｒｅＳＱＬ実行可能を生成するために、コンパイラのサンプル実行としてクエリ６だけが実行された。クエリ６は、ＦＤＯ最適化を適用して、両方のＤＢＭＳ上で再び実行された。普通のＰｏｓｔｇｒｅＳＱＬ上では、クエリ６の実行は１３５９ミリ秒かかった。ビーが有効なＰｏｓｔｇｒｅＳＱＬは、このクエリを９９０ミリ秒で評価した。性能向上は２７％であった。
上記の研究は、理想的な最適化を用いる場合であっても、マイクロ特化は、既存のコンパイラ最適化に加えて、顕著な向上を達成することが可能であることを示す。マイクロ特化の性能利点は、実行時命令の削減だけではない。実行されたコードサイズの削減は、クエリ評価中に命令キャッシュ圧力の低下を示す。
第９項：マイクロ特化の自動適用
マイクロ特化は、静的および動的プログラム解析を含む、複雑なタスクを必要とする。多様なマイクロ特化のタスクは、自動化された様式で実行することができる。
以下のステップを実行するために、多様なツールが提供される。これらのツールは、連携して、「高度に統合された開発環境（ＨＩＶＥ）」と呼ばれる。ＨＩＶＥの実装は、第９．２項で簡単に検討する。ＨＩＶＥは、関数バックエンドおよびＥｃｌｉｐｓｅプラグインベースのフロントエンドユーザインタフェースからなる。
９．１ マイクロ特化を適用するためのステップ
図２７は、マイクロ特化の適用を自動化するための具体的なタスクにそれぞれ対応するステップのシーケンスを含むプロセスのフローチャート４８０を示す。
ステップ１（ブロック４８２）。クエリ評価ループを識別する。ＤＢＭＳのかなり大きく複雑な実行可能コードからクエリ評価ループを表現するコード部分を正確に抽出するために、ＤＢＭＳ内部の基本ブロックの静的コールグラフが構築されてもよい。次いで、このグラフから強力に接続された構成要素が演算されてもよい。強力に接続された構成要素は、クエリ評価ループだけを表現する基本ブロックのセットを提供する。
例えば、この静的コールグラフ解析によって、リスト１に示されるｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ関数は、クエリ評価ループ内部にあると特定される。
ステップ２（ブロック４８４）。不変量を特定する。不変量を検出するには、動的解析が必要である。正確な実行時メモリアクセストレースを生成するために、ＶＡＬＧＲＩＮＤ等のプロファイルツールがクエリ評価と共に起動される。トレースは、（ａｄｄｒｅｓｓ，ｏｐｃｏｄｅ，ｏｐｅｒａｎｄ）の形式の三項のリストを含み、クエリ評価において値が不変量である変数を特定するために、以前に演算されたクエリ評価ループの基本ブロックセットおよび動的データフローグラフと組み合わせられる。クエリ評価中、特定のメモリ場所によって表される所定の変数が、（おそらく初期化中に代入によって）１回書き込まれてから、次いで、（クエリ評価ループ中に）複数回読み出される場合、このような変数は、可能性として実行時不変量として考えることができる。このようなメモリアクセスパターンは、実行トレースを解析することによって明らかにすることができる。
このような集中的な実行トレース等を収集することは、トレースレコードが命令あたりのベースで収集されるので、非効率的であり得ることに注意されたい。したがって、このようなトレースを解析することは、時間がかかるタスクである。マイクロ特化を適用することができる実行時不変量の１つの特徴は、これらの不変量は通常、分岐条件チェック文に関与することである。このため、ｃｍｐ命令全てはクエリ評価中だけに収集することができ、これによって、実行トレースを収集するオーバーヘッドを相当削減することができる。
このステップは、ＶＡＬＧＲＩＮＤの拡張が必要である。実行トレース生成を実現するために、代替のプロファイルツールも利用する（かつ拡張）ことができる。
ステップ３（ブロック４８６）。ソースコード内の不変量を究明する。不変量変数は次いで、ソースコードで定義されたデータ構造体にマッピングされる。特定された不変量は、オブジェクトコードでは、命令のオペランドとして表現される、メモリ場所である。これらの不変量の実際の参照および宣言を特定するために、命令をソースコードにトレースするために、ｄｅｂｕｇ＿ｌｉｎｅが利用される。
リスト１に示されるｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ関数内部のｎａｔｔｓおよびａｔｔａｌｉｇｎ等、実行時不変量変数を正確に示すため、プロファイル解析は静的プログラム解析と組み合わされなければならない。
ステップ４（ブロック４８８）。どのコードシーケンスがマイクロ特化されるべきかを決定する。次に、特に、各シーケンスの正確な境界を決定するために、特化されるターゲットコードシーケンスそれぞれが検証される。このために、静的データフロー解析に依存して、値が不変量であるコードシーケンスを特定する。これらのコードシーケンスは、コールグラフの早期またはそのリーフ近辺のいずれかに存在し得る。理想的な特化ターゲットは、短いコードシーケンス内部に比較的多数の使用を含む。
第２項で検討した事例研究の場合、ｓｌｏｔ＿ｄｅｆｏｒｍ＿ｔｕｐｌｅ関数内部の属性値抽出ループが特化された。
ステップ５（ブロック４９０）。ビーの関連タスクをいつ実施するかを決定する。異なる種類のビーに対して、第３．４項で検討した関連タスクは、異なる時点で実行されることが必要である。開発者は、最初に、５つのタスクの各々が適切な時点で実行されるように、ＨＲＥに組み入れることができるように、設計および作成されるビーの種類を決定することが必要である。
表３．１に従って、５つのタスクのコードがＨＲＥに実装された。
ステップ６（ブロック４９２）。ターゲットのソースコードは、ビールーチンを設計するために、スニペットに変換される。関係ビールーチンを検討する。このルーチンはおそらく、関係の属性すべてを処理する。属性の型に特化されるとする。実際の関係ビールーチンは、各々可能な型に対して１つのスニペットから構築されなければならず、スキーマに従ってステッチングされる。この特定の事例では、スニペットは、ｓｗｉｔｃｈ文から抽出される。別の例として、リスト１の１１行目の属性のｆｏｒループを検討する。そのループの本体からスニペットが作成される。
コードシーケンスに別の関数への呼び出しが含まれている場合、その呼び出しが、パラメータとして不変量値のうちの１つを渡すと、その呼び出された関数もまた、関数起動をインラインした後、このビールーチンの一部として特化される。（そうでなければ、ビーは関数呼び出しだけを保持する。）
第２項で検討したように、コードスニペットは、個別のコード分岐を利用することによって、関係およびタプルビーに対して設計され、各々が属性値抽出ループ内部の属性の所定の型を処理する。スキーマ定義時に、関係およびタプルビーのソースコードを形成するために、これらのコードスニペットが選択される。関係およびタプルビーソースコードの作成は、ＨＲＥ内に実装されたプロシージャによって行われる。実行時にソースコード作成が必要な任意の新しい種類のビーに対して、このタスクを実行するコードは、そのような種類のビー各々に実装されることが必要である。
ステップ７（ブロック４９４）。ビー起動およびサポートコードをＤＢＭＳソースに追加する。特化されたコードは、ここでＤＢＭＳから削除され、対応するビールーチンへの呼び出しで置換される。
ビーを追加すると、ＤＢＭＳの他の部分に影響を与える場合がある（希望的には、非常に限定された方式において）。第５項で検討したように、タプルビー内に記憶された属性はもはや関係そのものには記憶されない。ＴＰＣ−Ｈのｏｒｄｅｒｓ関係では、ｏ＿ｏｒｄｅｒｓｔａｔｕｓ、ｏ＿ｏｒｄｅｒｐｒｉｏｒｉｔｙ、およびｏ＿ｓｈｉｐｐｒｉｏｒｉｔｙという、３つの属性が特化され、これらは、小さい離散値ドメインを有する。これらの属性は、これらの値が各タプルにインスタンス化されたビーに記憶されるため、スキーマから削除される。この変更を有効にするために、コードをＤＢＭＳに追加しなければならない。
必要な関数呼び出しは、ＰｏｓｔｇｒｅＳＱＬに統合された。例えば、リスト３は、ＰｏｓｔｇｒｅＳＱＬに統合されたタプルビーを起動する、このような関数呼び出しを示す。
ステップ８（ブロック４９６）。確認実験性能解析を実行する。そのビーを利用すべきクエリ上に追加されたビー各々の性能利点を検証することが重要である。ビーが有効なＤＢＭＳおよび普通のバージョンを比較することによって性能を研究するためにベンチマークが利用される。詳細な研究は、クエリの実行時間、トランザクションのスループット、ならびに命令およびキャッシュ統計のプロファイルを含み、第８項に検討される。
第８項で詳細を記載するように、マイクロ特化の多くの利点を研究するために、包括的な性能解析を実施した。
これらの８つのステップは、本発明人がマイクロ特化を手動で適用した経験に基づいて、マイクロ特化を適用する際の既知の課題に対応するために提供される。これらのステップを実行する開発者を支援するために、マイクロ特化のプロセスを簡素化し、自動化することを目的とするツールセットが提供される。
９．２ ＨＩＶＥ：高度に統合された開発環境
ＨＩＶＥは、連携して、各マイクロ特化を実現するために必要な関連タスクを実行する、一連のツールからなる。
図２５は、ＨＩＶＥ４４２の上位アーキテクチャ４３０を表す。具体的には、この図に示される各ボックスは、８つのステップの中のいくつかのタスクを実施する施設を示す。直線は、制御フローを表し、破線は、データフローを表す。ＨＩＶＥ４４２は、ＥＣＬＩＰＳＥプラグインベースユーザインタフェース４３２を提供し、これによって、開発者は、マイクロ特化を適用するための８つのステップを実行するための一連のツールと相互作用することが可能になる。このユーザインタフェース４３２内部で、開発者は、実行可能プログラムの静的構造を研究するために、オブジェクトコードアナライザ４３４を起動することができる。具体的には、オブジェクトコードアナライザ４３４は、ＤＢＭＳ実行可能の静的コールグラフを解析し、クエリ評価内部ループを演算する（ステップ１）。この内部ループは、コールグラフとしても表現され、ユーザインタフェース４３２で視覚化することができる。オブジェクトコードアナライザ４３４は、動的実行解析を実施するために、プロファイルアナライザ４３６と連携して起動することができることに注意されたい。具体的には、オブジェクトコードアナライザ４３４によって生成される静的コールグラフは実行頻度によって増強され、実行されない関数が静的コールグラフから排除され、プログラムの実行時挙動のより正確な研究を可能にする（ステップ２）。
ユーザインタフェース４３２を使用することによって、開発者は、ソースコード内の不変量変数を識別する等、ソースコード研究を実施するためにソースコードアナライザ４３８を起動することができる。識別された変数は、ユーザインタフェース４３２を通じて視覚化される（ステップ３）。開発者は、ビーソースコードスニペットをＨＲＥ４４２に指定し、ビー起動文をＤＢＭＳに追加することによって、ビーを設計するためにソースコードアナライザ４３８を直接利用することもできる（ステップ４〜７）。
最後に、ＤＢＭＳ実行コントローラ４４０によって、ＤＢＭＳは、ユーザインタフェース４３２内部から稼動することが可能になり、実験目的で、必要な構成パラメータをカスタマイズすることが可能になる（ステップ８）ＤＢＭＳ実行コントローラ４４０は、オブジェクトコードアナライザ４３４によって解析される同じ実行可能ファイルであり得る、ＤＢＭＳ実行可能４４４を起動する。さらに、プロファイルアナライザ４３６は、開発者が、クエリ評価中に実行された命令数および多様なキャッシュミスレートを調査するために、複数のプロファイル結果を比較させる施設も提供する。
これらの一連のツールは、ツールがユーザインタフェース４３２から独立するように、モデルビューコントローラ（ＭＶＣ）［４］アーキテクチャでＨＩＶＥに統合される。事実、これらのツールのＡＰＩは汎用定義され、このため、ＥＣＬＩＰＳＥプラグイン以外の他の種類のユーザインタフェースを開発することができる。
図２６は、ＨＩＶＥメインユーザインタフェースの画面例４５０で、コールグラフ４５２が右側４５４（ＲＨＳ）に示される。具体的には、ＨＩＶＥはＥＣＬＩＰＳＥにプラグインとして統合される。ＨＩＶＥのユーザインタフェースは、左側４５６（ＬＨＳ）のリソースリストおよびＲＨＳ４５４の表示領域からなる。具体的に、この画面例４５０では、ｐｏｓｔｇｒｅｓ−ｓｔｏｃｋという名前のＨＩＶＥプロジェクトは、ＬＨＳリスト４５６に表示される。このようなプロジェクトはそれぞれユーザによって作成される。各プロジェクトは、ディスク上に記憶される、個別のプロジェクトディレクトリに関連付けられる。
このようなプロジェクトそれぞれの下に、各々がプロジェクトのディレクトリ内部のディレクトリとして示される、４つのノードが関連付けられる。これらは、オブジェクトファイル（Ｏｂｊｅｃｔ Ｆｉｌｅｓ）、性能解析（Ｐｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｓｉｓ）、プロファイル結果（Ｐｒｏｆｉｌｅ Ｒｅｓｕｌｔｓ）、およびソースファイル（Ｓｏｕｒｃｅ Ｆｉｌｅｓ）である。開発者は、各個別のノードを右クリックして、コンテキスト指向のポップアップメニューオプションを表示することができる。例えば、オブジェクトファイルノードのメニューオプションの１つは、オブジェクトファイルをロード（Ｌｏａｄ Ｏｂｊｅｃｔ Ｆｉｌｅ）である。このオプションを選択すると、ファイルブラウザが表示され、開発者は、バイナリオブジェクトファイルをロードするよう選択することができる。図２６が示すように、ｐｏｓｔｇｒｅｓ．ｂｉｎ４５８という名前の実行可能ファイルがロードされた。オブジェクトファイルがロードされると、ロードされたファイルと同一のコピーが作成され、オブジェクトファイル（Ｏｂｊｅｃｔ Ｆｉｌｅｓ）ディレクトリ内部に記憶される。これは、インストールされたバイナリファイルで、直接操作されない。代わりに、バイナリオブジェクトコードのあらゆる調査は、オリジナルファイルの同一コピー上で実施されなければならない。
ソースファイル、この事例では、ｐｏｓｔｇｒｅｓｑｌ−８．４．２−ｓｔｏｃｋソースファイルの場合、ロードされると、このディレクトリは、物理的にクローンされないことに注意されたい。そうではなく、ロードされたファイルはオリジナルのコピーで、直接修正することはできない。
性能解析ノードの下に、ｂｅｅ−ｅｎａｂｌｅｄ．ｐｅｒｆファイルが示される。このファイルは、ＪＤＢＣ接続文字列、実験用データベース名、および結果ディレクトリ名等、ＤＢＭＳを稼動し、実験を実施するための構成情報を含む。
プロファイル結果ノードは、ＶＡＬＧＲＩＮＤによって収集されたプロファイル結果を含むことができる。これらのプロファイルは、関連の実行時コールグラフおよび命令カウントを研究するために、特定のオブジェクトファイルと組み合わせて選択することができる。この例では、既存のプロファイルを提供しない。
図２６に示されるＲＨＳ４５４ビューは、マイクロ特化を適用する際の第１のステップに対応する。図示されるように、ＨＩＶＥは、左側（ＬＨＳ）４５６のツリービューおよびＲＨＳ４５４のパネルビューからなる。ＲＨＳは通常、関連情報を視覚化するためのメイン表示領域、および多様なタスクをトリガするためのボタンを含む操作パネルからなる。ＬＨＳツリーノードは、ソースコード、実行可能、プロファイル結果、および性能測定値等、解析対象項目に対応する。ＲＨＳ上に示される内容は、ＬＨＳ上で選択されたノードに依存する。例えば、図２６では、実行可能ファイル、ｐｏｓｔｇｒｅｓ．ｂｉｎ４５８が選択される。ＲＨＳ４５４はすると、オブジェクトコード解析関連オプションを表示する。この特定の事例では、バイナリ解析（Ａｎａｌｙｚｅ Ｂｉｎａｒｙ）ボタン４６０が示される。このボタン４６０をクリックすると、ＨＩＶＥは、選択されたオブジェクトファイルを解析し、静的コールグラフ４５２を演算する。ＨＩＶＥは、コールグラフから強力に接続された構成要素を識別することによって、関数呼び出しを体系化し、これは特に、ＤＢＭＳ実行可能からクエリ評価内部ループを明確にするために有用である。図２６に示されるように、強力に接続された構成要素は全て、強力に接続された構成要素（Ｓｔｒｏｎｇｌｙ Ｃｏｎｎｅｃｔｅｄ Ｃｏｍｐｏｎｅｎｔｓ）というＨＴＭＬタブ４６２に列挙される。タブ４６２内部で特定の強力に接続された構成要素を選択すると、この事例では、「ｃｏｍｐｏｎｅｎｔ＿４２ Ｄｉａｇｒａｍ」という名前の新しいタブ４６４内に視覚化されたコールグラフ４５２が作成される。
９．３ マイクロ特化を適用するためにＨＩＶＥを利用する
上記の図２７を参照して、マイクロ特化が適用される８つのステップを検討する。以下の８つのステップの参照では、ＨＩＶＥとマイクロ特化を適用する開発者との間の相互作用に重点を置く。
ステップ１（ブロック４８２）。クエリ評価ループを識別する。開発者は、ＬＨＳ上のオブジェクトファイル（Ｏｂｊｅｃｔ Ｆｉｌｅｓ）ノードにＤＢＭＳ実行可能バイナリをロードする。新しく追加されたオブジェクトファイルが選択されると、ＲＨＳビューは、実行可能に関する一般情報を表示する。さらに、図２６に示されるように、バイナリ解析（Ａｎａｌｙｚｅ Ｂｉｎａｒｙ）というボタンがＲＨＳビューの最上部に表示される。このボタンをクリックすると、オブジェクトコードアナライザが起動して、静的コールグラフを構築し、クエリ評価ループを表す強力に接続された構成要素を識別する。視覚化目的のために、図２６は、クエリ評価ループを表さない、８つの関数を含む、単一の強力に接続された構成要素を示すことに注意されたい。
ステップ２（ブロック４８４）。実行トレースで不変量を識別する。不変量は、ＶＡＬＧＲＩＮＤを利用することによって生成される、実行時プロファイルに依存する、動的解析で識別される。
ステップ３（ブロック４８６）。ソースコード内の不変量を究明する。このステップの目標は、実行時不変量を表す、ソースコード内の宣言をハイライトすることである。したがって、開発者は、ＬＨＳ上のソースファイル（Ｓｏｕｒｃｅ Ｆｉｌｅｓ）ノードの下にノードとして表される、ＤＢＭＳソースコードディレクトリにロードすることが必要である。不変量を識別し、ハイライトするためのオプションは、開発者がオブジェクトファイルノード（ｐｏｓｔｇｒｅｓ．ｂｉｎ等）および関連のプロファイルノード（この場合、ｈｉｖｅ．ｔｒａｃｅ．１９０５１．ｐｒｏｆｉｌｅファイル）を複数選択すると表示される。ＲＨＳ表示は、いくつかのタブを示し、各々、不変量がハイライトされているソースコードファイルを表す。図２８は、開発者によって選択され、このためＲＨＳ４５４のソースコードビューでハイライトされた不変量変数５０８を含むＨＩＶＥの画面例５００を示す。この図では、１１行目で定数値０ｘ１２３４５が代入されたｉｎｔ ｃという明らかな不変量変数５０８を含む、非常に単純なプログラムが示される。この変数５０８は次いで、１５行目に示されるｉｆ文で利用される。ステップ３は中間ステップであることに注意されたい。不変量をハイライトすることは、検証目的に過ぎない。本番では、不変量を正しく識別することは、ＨＩＶＥによって完全に管理されるべきである。このため、連続するステップでソースコードを明示的に注釈する必要性は存在しない。
この特定の不変量がどのように識別されるかをここで説明する。ＬＨＳ上で、ｈｉｖｅ．ｔｒａｃｅ．１９０５１．ｐｒｏｆｉｌｅという名前のプロファイルファイル５１６が選択される。このプロファイルは、ＶＡＬＧＲＩＮＤによって生成される。具体的には、このファイルは、プログラムの実行中に各命令が実行される直前の命令のシーケンスおよび登録値を含む。この場合、プログラムは、オブジェクトファイル（Ｏｂｊｅｃｔ Ｆｉｌｅｓ）ノードの下に示されるように、ｓｉｍｐｌｅ．ｂｉｎと命名される。
プロファイルファイル５１６がＬＨＳ４５６上で選択されると、ＲＨＳ４５４は、３つの列からなるインタフェースを表示する。図２８に示されるように、操作（Ｏｐｅｒａｔｉｏｎｓ）列５０４では、開発者は、まず、現在選択されたプロファイルファイル５１６が、実行可能プログラムを実行することによって生成されたことを示すために、オブジェクトファイルボタン５１２とのリンクをクリックすることが必要であり、これは、このボタンをクリックした後にファイルブラウザで選択される。ＨＩＶＥは、実行可能ファイルに対してプロファイルデータを解析し、それらのタイプによって命令を分類する。マイクロ特化は分岐文に存在する実行時不変量を識別することを中心とすることから、ＣＭＰ（比較）命令が現在サポートされる。上位命令取得（Ｇｅｔ Ｔｏｐ Ｉｎｓｔｒｕｃｔｉｏｎ）ボタン５１４をクリックすると、１００の最も頻繁に実行されたＣＭＰ命令（＃ｉｎｓｔｒボックスによって指定される）が下のリスト内部に表示される。この単純なプログラムの場合、合計で３つのＣＭＰ命令だけが識別される。リストの２番目のＣＭＰ命令を選択すると、ＲＨＳ４５４のソースコード（中央の）列が、選択された命令を含むソースコードを表示する。さらに、選択された命令に対応する文がハイライトされる。一番右側の列には、選択されたＣＭＰ命令のオペランドの値が表示される。変数ｃには定数０ｘ１２３４５が代入され、他の比較オペランドも０ｘ１２３４５であるため、一番右の列に表示された両方の値が０ｘ１２３４５であることがわかる。最後に添付された値１０００は、特定のオペランドと値の組み合わせが何回発生するかを示し、ソースコード内で、ｉｆ文が１０００回反復するｆｏｒループ内部で実行されることを確認することができる。
識別された不変量が存在するソースファイルを視覚化するためのより直感的な代替方法は、各個別の不変量変数を個別の色に割り当て、さらに各ソースファイルに対してＬＨＳ上に注釈することで、色の帯の組み合わせが、含まれた不変量変数すべてを示す。
ＨＩＶＥは通常、開発者によって不変量を識別する手動操作を必要とせず、実行時メモリアドレスによって表されるだけであることに注意されたい。そうではなく、これらの２つのステップは、動的および静的バイナリコード解析を使用して、ＨＩＶＥによって全体的に自動化される。
ステップ４（ブロック４８８）。どのコードシーケンスがマイクロ特化されるべきかを決定する。ＨＩＶＥは、不変量の参照を識別するために、データフロー解析を利用する。この解析が完了すると、ＨＩＶＥは、特化される候補のコードシーケンスを示唆する。開発者は、次いで、予め選択されたコードシーケンスの境界を調整することが可能である。境界の選択は、２つの条件に依存することに注意されたい。まず、多量のビーは、特に多数が起動される場合、相当なキャッシュ圧力を導入することになるため、コードシーケンスはわずかでなければならない。第２に、特化されるコードセグメントは、関数呼び出しはビーインスタンス化中の複雑性を示すため、できる限り少ない関数呼び出しを含まなければならない。事実、特化されるコードセグメントの選択が分岐指向であることから、１つの直感的な選択条件は、分岐文によってコードセグメントの境界を決定することになる。
このステップは、フロントエンドのソースコードビュー内部で実施される。
ステップ５（ブロック４９０）。ビーの関連タスクをいつ実施するかを決定する。第３．３項で検討したように、異なる種類のビーに対する５つのタスクは多様なタイミングで実施される。たとえば、全てのバージョンの結合アルゴリズムおよび述語評価クエリプロトビーは、データベースが作成されるときに生成することができる。一方、関係プロトビーは、スキーマ定義時点のみに生成することができる。関係ビーは、スキーマ定義時にインスタンス化されるが、クエリビーは、クエリがＤＢＭＳによって受信された後のみにインスタンス化できる。開発者は最初にビールーチンを設計し、次に、ＨＩＶＥに対し、設計された特化コードが存在すべきビーの種類、およびビールーチンが作成、生成、およびインスタンス化されるべきタイミングを記述する。上記のタスクをソースコードに記述するために、ソースコード注釈を採用できることに注意されたい。しかし、上記のタスクは、開発者が関与せず、ＨＩＶＥによって自動的に実施されるべきである。
ステップ６（ブロック４９２）。ターゲットのソースコードは、ビールーチンを作成するために、スニペットに変換される。指定されたコードシーケンス内部から、ＨＩＶＥは、示された分岐に従ってコードスニペットを自動的に抽出してもよい。開発者は、生成されたコードスニペットを手動で修正することができる。さらに、開発者は、関連およびタプルビーのため等、コードスニペットからビーソースコードを作成するために、関連関数を実装する。
ステップ７（ブロック４９４）。ビー起動およびサポートコードをＤＢＭＳソースに追加する。上記のステップが達成されると、現在のマイクロ特化の適用は、ビーソースコードを作成し、プロトビーを生成し、ビーをインスタンス化するために、適切な起動文をＤＢＭＳに埋め込むことによって、全てＨＲＥへの呼び出しとして、最終化されることが必要である。また、コードシーケンスが、特化されることが決定されると、開発者は、ステップ５に応じて、ビー作成、生成、およびインスタンス化を実施する関連コードをＨＲＥのビーメーカー構成要素に組み入れることが必要である。このステップは、ソースコードビューで実行されるべきである。
ステップ８（ブロック４９６）。確認実験性能解析を実行する。ビーが配置され、ＤＢＭＳが再度コンパイルされた後、開発者は、性能を測定して研究するための実験を開始することができる。プロファイリングおよび実行時間測定の２つのオプションが提供される。開発者は、特化が適用されたＤＢＭＳおよび普通のバージョン両方でベンチマークを実行することができる。
図２９は、プロファイル結果比較ビューを示す画面例５３０を提供する。この例では、ＬＨＳ４５６上のハイライトされたプロファイルノードとして示される、ｇｃｌ＿ｅｖｐ＿ｅｖｊ＿０７１３２０１１およびｓｔｏｃｋ＿０７１１２０１１という２つの組のプロファイル５３２および５３４がそれぞれ選択される。デュアルプロファイルの選択によって、ＲＨＳ４５４は、実行時間データの比較ビューを示し、開発者が比較を実施することを可能にする。この特定の画面例が表示するように、ＴＰＣ−Ｈクエリの評価中に実行された命令の数（コンフィグ（ｃｏｎｆｉｇ）ペイン５４０のＩｒチェックボックス５３６を選択することによって示される）が研究される。２つの組のプロファイルが比較される。１つの組のプロファイルは、普通のＰｏｓｔｇｒｅＳＱＬで収集される。他の組は、ビーが有効なＰｏｓｔｇｒｅＳＱＬで収集され、ＧＣＬ、ＥＶＰ、およびＥＶＪビールーチンが有効であった。比較（Ｃｏｍｐａｒｅ）ボタン５４２をクリックすると、結果テーブルは詳細統計データで更新される。
ＨＩＶＥは、解析されるデータのグラフ視覚化を提供する。この特定の例では、開発者は、Ｘ軸をＴＰＣ−Ｈクエリ番号であるＩＤに、Ｙ軸はＩｒに指定する。次に、開発者は、この表の選択された列を視覚化するバーチャートを生成するために、図を生成（Ｇｅｎｅｒａｔｅ Ｆｉｇｕｒｅ）ボタンをクリックする。具体的には、開発者は、プロファイル収集アナライザ５４６の左下の図（Ｆｉｇｕｒｅ）タブ５４８をクリックする。生成されたバーチャート５５４は、図３０に示されるように、このタブに表示される。加えて、生成されたチャートとともに統計要約５５８が表示される。図３０に表示されるこのバーチャート５５４は、第８項の図１２に対応することに注意されたい。
９．４ マイクロ特化を実際に適用する
この研究では、マイクロ特化を特定のＤＢＭＳ、実際には特定のバージョン（ＰｏｓｔｇｒｅＳＱＬ８．４．２）に適用することに重点が置かれた。しかし、現実には、ＤＢＭＳコードレポジトリは頻繁に変化し、マイナーおよびメジャーリリースが定期的に発表される。このようなＤＢＭＳにおける頻繁な変更は、マイクロ特化に影響を与えかねない。究極的に、ＤＢＭＳのソースコードが変更されると、ビーが最初に適用された不変量が変更されている可能性があるため、既存のビーが生成されることが必要な場合がある。すなわち、影響を受けるビーを更新するために、第９．１項で検討された８つのステップが再び実施されることが必要である。これらの８つのステップの複雑度から、このセクションでは、ステップ全体を再度実行することが必要かどうか、または再実行を簡素化することができるか、各ステップに関して検討が提供される。８つ全てのステップで、ＨＩＶＥは、そのステップで生成された結果を記録することが必要であることに注意されたい。たとえば、第１のステップによって生成されるクエリ評価ループは、記憶されることが必要である。これらの結果は次いで、ＤＢＭＳが変更された後、そのステップを高速化または実施を排除するために、使用されることが可能である。
クエリ評価ループを識別する第１のステップでは、ＤＢＭＳソースコードが変更されると、変更がクエリ評価ループに影響を与えるかどうかを判定することが必要である。この解析は、クエリ評価中に起動される関数全てを提供する、以前に演算されたクエリ評価ループに依存する。このループ内部のいずれかの関数のソースコードが変更されると、このステップは再実行されることが必要で、次いで、次のステップに進むことができる。変更は、クエリ評価ループに多様な程度の影響を与える場合があることに注意されたい。たとえば、関数をループの内外に移動する等、ループのアーキテクチャを変更すると、その後の７つのステップ全てに全体的に再実行しなければならない。一方、変更が内部ループの以前の構造を無効にしない、わずかな関数に限定される場合、第２のステップは、ステップの残り全てを再実行させなくても、直ちに検討されるはずである。このステップの後、新しいクエリ評価ループが演算され、記憶される。
ソースコード内の変更が必ずしもそれまでに識別された不変量全てに影響を与えるわけではない場合があるので、不変量を識別する第２のステップは、完全に再実行される必要がなくてもよい。このステップは、収集される実行プロファイルが必要で、時間がかかりかねない。ＨＩＶＥは、プロファイル結果がそれまでのプロファイルから異なるようになる、ＤＢＭＳソースコードへの変更が所定の実行サンプルに影響を与える可能性があるかどうかを決定しなければならない。影響を受ける実行サンプルだけを再実行することが必要である。さらに、新しい関数をクエリ評価ループに組み込むとき、新しい不変量が発見されるかもしれない。この場合、ＤＢＭＳの開発者は、新しく導入されたコードを網羅する実行サンプルを提供しなければならず、このため、新しく追加されたコードは、不変量の存在について解析することができる。
第３のステップは、ソースコード内の変数またはデータ構造に対する実行プロファイルで検出された不変量を識別する。ＤＢＭＳソースコードへの変更によって影響を受ける不変量、ならびに出現する新しい不変量だけが、この第３のステップで識別される必要がある。
同様に、第４のステップでは、コードシーケンスがマイクロ特化に選択された場合、第３のステップで再識別された変数およびデータ構造を参照するコードシーケンスだけが再検討される必要がある。
汎用ソースコードをビーコードスニペットに変換し、ビールーチンを設計し、ＤＢＭＳにビー起動を追加する、多様なビー関連タスクの割り当てを実施する第５〜７のステップはそれぞれ、影響を受ける不変量に関してのみ部分的に再実行される。
適用されたビーの性能を評価する、第８のステップは、特に他の既存のビーに対する影響について、新しく修正されたビーの性能利点を研究するために、概して再実行されなければならない。
一般に、ＨＩＶＥは、各ステップに必要な作業を示し、予測するために、ユーザインタフェースを含まなければならない。特に、開発者が時間および予算制約にしたがって選択を行うことができるように、ステップ全体を再実行することに関する概算作業および時間と、ステップを部分的に再実行するための作業および時間との間の比較が所望される。
第１０項：実行時値を可能にするようにテンプレート機構を拡張する
実行時コード特化技法を利用することによって、ＤＢＭＳ性能を向上する手法として、マイクロ特化が導入された。具体的には、実行時に実行可能コードを選択し、生成する際に重要なステップである、ビーのインスタンス化は、（Ｃ＋＋またはＪａｖａ（登録商標）のジェネリックスで使用される）テンプレートによって導入されるインスタンス化機構に非常に類似する。テンプレートインスタンス化機構によって、入力引数の型に特異的な関数等、コードを動的に選択する機能が、生成された実行可能コードに導入されることを可能にする。しかし、従来のテンプレートは、コンパイル時にインスタンス化をトリガする。このため、究極的にマイクロ特化によって実行時に利用される中心技法である、変数値ベースのインスタンス化は、従来のテンプレートによって直接影響され得ない。
１０．１ 動的テンプレート
実行時に値ベースのコード特化を適用可能にすることができる、テンプレート機構の拡張を検討する。第１０．２項において、動的テンプレートをマイクロ特化でどのように使用できるかについての検討を提供する。ＰｏｓｔｇｒｅＳＱＬに実装されたＥｘｅｃＥｖａｌＳｃａｌａｒＶａｒ関数は、実行時コード特化の状況で、テンプレート機構をどのように強化することができるかについて検討するために、例として利用され、リスト６に示される。
リスト１６によって示されるように、従来のＣで表現されるＥｘｅｃＥｖａｌＳｃａｌａｒＶａｒ関数は、３つの分岐を含む。この関数は、ＰｏｓｔｇｒｅＳＱＬのソースコードから直接得られた。９行目の分岐文（ｓｗｉｔｃｈ）は、ｖａｒｉａｂｌｅ−＞ｖａｒｎｏ変数に記憶される、入力タプルの入力源を検証し、これに応じてどの分岐を実行する化を決定する。
ＥｘｅｃＥｖａｌＳｃａｌａｒＶａｒ関数は、関数テンプレートに変換される。動的テンプレートベースの特化を示すために、対応するテンプレート定義およびインスタンス化の例をリスト１７に示す。この関数テンプレート定義に示されるように、第１行目に示されるｉｎｔ ｖａｒｎｏという、テンプレート引数が導入される。コードは、実行する特定の分岐を決定するために、このテンプレート引数を使用する。３つの個別のコード分岐だけが存在することから、ＥｘｅｃＥｖａｌＳｃａｌａｒＶａｒ関数は、３つのバージョンにコンパイルすることができ、各々特定の分岐に具体的に対応する。
リスト１８は、ＥｘｅｃＥｖａｌＳｃａｌａｒＶａｒ関数の特化されたソースコードを示し、ｖａｒｎｏテンプレート変数がＩＮＮＥＲ（分岐）値に割り当てられる。リスト１７に示される２５行目の関数呼び出し文が、テンプレート変数の値として、ＩＮＮＥＲで起動されると、リスト１８に示される特化された関数が起動されることに注意されたい。
前の作業で、ｖａｒｎｏの値は、コンパイル時定数であることが必要である。しかしながら、マイクロ特化内部では、変数は、テンプレートパラメータとして指定されることが可能である。動的テンプレートベースの特化は、実行時値によって特化されるルーチンの起動を許可するために、Ｃ＋＋言語等のテンプレートを汎用化する。
実行時、リスト１７の２５行目に示されるように、関数起動文は、関数テンプレートパラメータとして、入力タプルの入力源を表す、ｖａｒｎｏという名前の変数を提供する。第６．２項に記載されるように、ｖａｒｎｏ変数の値、この場合、テンプレートパラメータは、ターゲットプロトビーバージョンにマッピングされる。このため、ビーの正しい分岐（バージョン）を起動することができる。
この動的テンプレートベース特化機構を採用することによって、実行時コード特化は、良好に構造化された様式で実現することができる。特化ソースコードの作成、オブジェクトコードの生成、起動、および他の操作は、コンパイラによって完全に管理される。
さらに、テンプレート機構のこのような汎用化は、最適化機会を導入する。例えば、コンパイラは、静的、動的、またはハイブリッド様式で、関数等、コードのストレッチに複数バージョンを生成するように選択することができる。
わずかなコード分岐だけが存在する場合、コンパイラは、コンパイル時に可能なバージョン全てを生成することができる。静的に生成されたコードは、次いで、実行時に直接起動することができる。しかし、多数の分岐が存在する場合、バージョン全てを生成すると、得られるコードを管理する空間の複雑度を顕著に増加する可能性がある。リスト１７の第２５行目の関数呼び出しは、ｖａｒｎｏテンプレートパラメータの値から、テンプレート関数をコンパイルするためにコンパイラを動的に起動することができる。
このため、コンパイラは、特定の分岐が実行される場合、実行時にのみコードを動的にコンパイルすることを決定することができる。ハイブリッド手法では、プロファイルガイド解析は、所定の頻繁に実行されるコード分岐を識別することを補助することができる。コンパイラは、コンパイル時に頻繁に実行される分岐だけのオブジェクトコードを静的に生成することができる。このため、他の分岐は、実行時に動的にコンパイルされなければならない。ここで検討される動的なコード生成、起動、および必要な管理は、マイクロ特化手法に類似する実装を使用して実現することができる。具体的には、プロトビー管理の実装は、この動的テンプレート機構を実現するために、ここで直接利用することができる。唯一の違いは、変数ベースのテンプレートパラメータを示すために、動的テンプレートには構文注釈が必要である点である。
１０．２ マイクロ特化に動的テンプレートを採用する
マイクロ特化の適用中の１つのタスクは、汎用ソースコードを特化コードスニペットに変換することである。変換は現在、事例ベースで手動で実行される。すなわち、それぞれの種類のビーに対して、ビーソースコードを作成するために、異なる手法が利用される。事例特異的手法は、それぞれの種類のビーが適切に作成できることを保証するが、この手法の複雑性は、このタスクの自動化を困難にする。したがって、ビー作成および生成を自動化する際に関与する高度化を活用するための技法が採用されてもよい。
第１０．１項では、ＨＲＥを利用することによって、テンプレート機構をどのように拡大できるかについて検討し、その結果、動的テンプレートとなった。ここでは、マイクロ特化を適用する際、特に、ビー作成および生成のステップにおいて、静的テンプレートの正確さを継承する、動的テンプレートをプログラム言語構成概念としてどのように適用することができるかについて検討する。
リスト１７に示される例が示すように、動的テンプレートは、クエリビーの作成および生成タスクを実施するために利用することができる。具体的には、汎用コードセグメント内部の究極的には個別のコード分岐である、クエリプロトビーが、ＤＢＭＳ開発と共に設計および作成されることから、動的テンプレートは、汎用コードを特化クエリビーコードに手動で変換することなく、クエリビーを有効にするためにＤＢＭＳソースコードに組み入れることができる。動的テンプレートのコンパイル中、コンパイラは、動的テンプレートの全てのバージョンを生成し、各バージョンがプロトビーである。さらに、ホットスワップを実施することができるクエリビーに関して、このようなビーを作成および生成するために、動的テンプレートを採用することもできる。コンパイラは、実行のフローを制御する変数の値のシーケンスによって要求されるビーのバージョン全てを決定し、このため、それに応じてビーコード内のホットスワッピング文でビーを生成することができる。クエリビーはＤＢＭＳ開発時に作成され、ＤＢＭＳコンパイル中に生成されることから、これらのタスクを実現するために動的テンプレートを適用することができ、テンプレートの作成および生成は、クエリビーのタスクに整合される。
事実、ホットスワッピングを必要としない通常のクエリビーの場合、ビー起動によってインライン機能を利用することができ、ビーコードがコンパイル時に呼び出し元コードに埋め込むことができる。インライン機構の欠点は、リスト１６に例示したようなコード分岐は全て、ビーにコンパイルされ、呼び出し元に組み込まれることである。これによって、生成されるＤＢＭＳ実行可能コードのサイズが増加する。さらに、分岐条件は全て、特定の分岐だけが実際に実行される場合であってもまだ評価される。
関係ビーおよびタプルビーの場合、それらの作成および生成がＤＢＭＳコンパイルの後である、ＤＢＭＳ実行時であるという事実に起因して、どちらの種類のビーでもこれらのタスクを実施するために動的テンプレートを採用することはできない。すなわち、動的テンプレートのコード生成は、コンパイル時に要求される。しかしながら、関連およびタプルビーのコード生成は、実行時に要求される。
第１１項：他の実施形態
ビーを並列実行する
マイクロ特化の重要な特徴は、特化実行可能コード、すなわち、ビーの実行時起動である。ビーは通常、相互に独立してタスクを実行する。例えば、特定の関係のタプルビーは全て、タプルから値を抽出し、これらのタプルで述語を評価するとき、独立的に並列に実行することができる。したがって、１度に１つのタプルクエリ評価モデルを採用する代わりに、多数のタプルをフェッチすることによって、属性値抽出および述語評価を並列に実行し、このような演算の効率を顕著に向上するために１度に全ての関連タプルビーを起動することができる。
マイクロ特化の利点は、ＤＢＭＳ内部の非常に下位で適用されることである。従来のＤＢＭＳ内部でクエリ評価全体を並列に実行することは困難であるが、並列性は、マイクロ特化の柔軟性および微細な適用粒度によって達成することができる。
最新のＣＰＵは通常、独立的に動作することができるマルチコアが装備されている。このようなアーキテクチャ上の発展は、ビーの並列実行を利用するマイクロ特化の適用に対する機会を提供する。さらに、現在のＧＰＵは、非常に積極的な並列コード実行を促進することができる。ビーが小さいことから、ＧＰＵは、多数のビーを並列で実行させる理想的なプラットフォームを提供してもよい。
ビー効果をクエリオプティマイザのコストモデルに組み入れる
ＤＢＭＳは、効率的なクエリ評価のために最適なクエリ評価計画を生成するためにクエリオプティマイザを採用する。クエリオプティマイザは通常、特定の計画の全体的なコストを概算することができるコストモデルに依存する。したがって、多様な候補計画の間でこのようなコストを比較することによって、実行するための最適計画を選択することができる。
コストモデルは通常、シーケンシャルスキャン、ハッシュ演算、またはソート操作を実施するオーバーヘッド等、所定の既知の定数に基づく。
ビーの利用が影響を受ける計画演算子の効率性に直接影響することから、ビーが有効なＤＢＭＳのコストモデルは、ビーの存在に合わせて調整することができる。いくつかの場合には、古い定数値を、関連ビーの影響を考慮する新しい値に置換する代わりに、ビーはさらなるコンパイルを導入されてもよい。例えば、ホットスワップするビーは、特定のビーが実行のためにスワップされるたびに、演算子に対して異なる性能影響を有する。ビーのこの動的な性質に対処するために、ビーを用いてクエリ計画生成を向上する際の機会は、ホットスワップが関与するクエリ評価中に、各ビーが何回実行されるか等、微細粒度の解析を処理するためにコストモデル内部で利用されてもよい。
マイクロ特化を積極的に活用する
タプルビーは、関係内の属性値を特化することによって作成される。究極的に、列全体が特化された関係から削除される。いくつかの実施形態において、タプルビーは、特化属性が制限値ドメインを有する場合にのみ利用される。より積極的にマイクロ特化を適用するために、この制限を緩和することができ、これらの属性のうちの一部に関するタプルビーを可能にすることができる。具体的には、属性の値の分散を利用することができ、高い発生率を有する値に関してのみ特化することができる。
加えて、修正およびページビー等、他の種類のビーをＨＲＥに組み入れてもよい。このような拡張は、ＨＲＥ ＡＰＩに追加の関数を導入してもよい。
さらに、マイクロ特化は、他の種類のＤＢＭＳに適用されてもよい。例えば、ＭｏｎｅｔＤＢおよびＶｏｌｔＤＢは、アーキテクチャの点で、従来の関係ＤＢＭＳとは非常に異なる。
バイナリコードからビーを生成する
現在、マイクロ特化は、ビーソースコードを作成するために、ＤＢＭＳのソースコードに依存する。いくつかの実装において、ＤＢＭＳのオブジェクトコードを直接修正することによって、ビーを生成し、ビーの起動を有効にするためにＤＢＭＳのバイナリ実行可能コードを直接利用することが有利な場合がある。バイナリコードからビーを生成する明らかな利点は、ソースコードの高価なコンパイルを回避できること、およびプロトビーの可能性があるバージョン全てをコンパイルすることを回避できることであり、コンパイルのコスト、および多数のバージョンのプロトビーを記憶するために必要な空間要件を削減する。
ＨＩＶＥを用いてマイクロ特化の適用を自動化する
いくつかの実施形態において、ＨＩＶＥツールセットによって、ＤＢＭＳ開発者は、ＤＢＭＳにおけるビーを設計し、実装するために、必要な静的コード解析、動的なプロファイル収集および解析、および実行時性能解析を実施することが可能になる。いくつかの実装において、このような半自動化プロセスは、第９項に記載の８つのステップによって構造化され、ユーザが一切関与することなく、完全に自動化することができる。このような自動化は、多数の種類のＤＢＭＳ内部にマイクロ特化を積極的に適用するために有用である。完全に自動化されたマイクロ特化は、導入されるビーの解析および調整に正確性も提供する。最後に、第５項および６項に検討したように、ビーを作成、生成、およびインスタンス化するコストは、特にこれらのタスクがＤＢＭＳ実行時に必要である場合、マイクロ特化適用時に考慮することが必要である。マイクロ特化が所与の所定のシナリオで利点があるかどうかを自動的に決定することができるコストモデルをＨＩＶＥが導入してもよい。
引用参考文献（本明細書に参照により組み入れる）
［１］Ｊ．Ｂｏｎｗｉｃｋ．Ｔｈｅ Ｓｌａｂ Ａｌｌｏｃａｔｏｒ：Ａｎ Ｏｂｊｅｃｔ−Ｃａｃｈｉｎｇ Ｋｅｒｎｅｌ Ｍｅｍｏｒｙ Ａｌｌｏｃａｔｏｒ．Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ Ｕｓｅｎｉｘ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ，ｐａｇｅｓ ８７−９８，Ｊｕｎｅ １９９４．
［２］Ｂ．Ｃａｌｄｅｒ，Ｐ．Ｆｅｌｌｅｒ，ａｎｄ Ａ．Ｅｕｓｔａｃｅ．Ｖａｌｕｅ
Ｐｒｏｆｉｌｉｎｇ ａｎｄ Ｏｐｔｉｍｉｚａｔｉｏｎ．Ｊｏｕｒｎａｌ ｏｆ Ｉｎｓｔｒｕｃｔｉｏｎ Ｌｅｖｅｌ Ｐａｒａｌｌｅｌｉｓｍ，ｖｏｌ．１，Ｍａｒｃｈ
１９９９．
［３］Ｖａｌｇｒｉｎｄ Ｄｅｖｅｌｏｐｅｒｓ．Ｃａｌｌｇｒｉｎｄ：Ａ Ｃａｌｌ−Ｇｒａｐｈ Ｇｅｎｅｒａｔｉｎｇ Ｃａｃｈｅ ａｎｄ Ｂｒａｎｃｈ Ｐｒｅｄｉｃｔｉｏｎ Ｐｒｏｆｉｌｅｒ．
［４］Ｒ．Ｅｃｋｓｔｅｉｎ．Ｊａｖａ ＳＥ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｓｉｇｎ
ｗｉｔｈ ＭＶＣ．
［５］Ｒ．Ｅｌｍａｓｒｉ ａｎｄ Ｓ．Ｎａｖａｔｈｅ．Ｆｕｎｄａｍｅｎｔａｌｓ ｏｆ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ．Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ，ｓｉｘｔｈ ｅｄｉｔｉｏｎ，Ａｐｒｉｌ ２０１０．
［６］Ｌｉｎｕｘ Ｆｏｕｎｄａｔｉｏｎ．ＥＬＦ ａｎｄ ＡＢＩ ｓｔａｎｄａｒｄｓ．
［７］Ｉｎｃ．Ｆｒｅｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ．Ｏｐｔｉｍｉｚａｔｉｏｎ Ｏｐｔｉｏｎｓ−Ｕｓｉｎｇ ｔｈｅ ＧＮＵ Ｃｏｍｐｉｌｅｒ Ｃｏｌｌｅｃｔｉｏｎ （ＧＣＣ）．
［８］Ｋ．Ｋｒｉｋｅｌｌａｓ，Ｓ．Ｖｉｇｌａｓ，ａｎｄ Ｍ．Ｃｉｎｔｒａ．Ｇｅｎｅｒａｔｉｎｇ Ｃｏｄｅ ｆｏｒ Ｈｏｌｉｓｔｉｃ Ｑｕｅｒｙ Ｅｖａｌｕａｔｉｏｎ．Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ（ＩＣＤＥ），ｐａｇｅｓ ６１３−６２４，２０１０．
［９］Ｄ．Ｌｕｓｓｉｅｒ．ＢｅｎｃｈｍａｒｋＳＱＬ．
［１０］Ｒ．Ｍｕｔｈ，Ｓ．Ｗａｔｔｅｒｓｏｎ，ａｎｄ Ｓ．Ｋ．Ｄｅｂｒａｙ．Ｃｏｄｅ Ｓｐｅｃｉａｌｉｚａｔｉｏｎ Ｂａｓｅｄ ｏｎ Ｖａｌｕｅ Ｐｒｏｆｉｌｅｓ．Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｔｉｃ Ａｎａｌｙｓｉｓ Ｓｙｍｐｏｓｉｕｍ（ＳＡＳ），ｐａｇｅｓ ３４０−３５９，Ｊｕｎｅ
２０００．
［１１］ＰｏｓｔｇｒｅｓＳＱＬ Ｇｌｏｂａｌ Ｄｅｖｅｌｏｐｍｅｎｔ Ｇｒｏｕｐ．ＰｏｓｔｇｒｅｓＳＱＬ：Ｄｏｃｕｍｅｎｔａｔｉｏｎ ８．４：Ｒｅｓｏｕｒｃｅ Ｃｏｎｓｕｍｐｔｉｏｎ．
［１２］ＴＰＣ．ＴＰＣ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｕｎｃｉｌ −ＴＰＣ−Ｃ．
［１３］ＴＰＣ．ＴＰＣ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｕｎｃｉｌ−ＴＰＣ−Ｈ．
本明細書に参照および／または本明細書のデータシートに挙げられた上記の米国特許、米国特許出願公開、米国特許出願、外国特許、外国特許出願、および特許以外の文献は、それらの全体を参照によって本明細書に組み入れる。
前述の記載の実施形態は、異なる他の構成要素内部に含まれた、または異なる他の構成要素と接続された異なる構成要素を表す。そのような表されたアーキテクチャは例示に過ぎず、事実、同じ機能を達成する、多数の他のアーキテクチャが実装できることを理解されたい。概念的には、同じ機能を達成するための構成要素の配置は、所望の機能が達成されるように、効果的に「関連付けられる」。したがって、特定の機能を達成するために組み合わされた本明細書の任意の２つの構成要素は、アーキテクチャまたは中間構成要素に無関係に、所望の機能が達成されるように相互に「関連付けられる」と考えることができる。同様に、そのように関連付けられた任意の２つの構成要素は、所望の機能を達成するために相互に「動作可能に接続」、または「動作可能に連結」すると考えることもできる。
本発明の特定の実施形態が示され、記載されるが、当業者には、本明細書の開示に基づいて、本発明およびそのより広義の態様から逸脱することなく変更および変形を行うことができること、したがって、添付の請求項は、そのような変更および変形全てが本発明の真の精神および範囲であるとして、それらの範囲内に及ぶことが明らかであろう。さらに、本発明は添付の請求項のみによって定義されることを理解されたい。一般的に、本明細書、および特に添付の請求項（すなわち、添付の請求項の本文）に使用される用語は、一般的に、「限定されない」用語（すなわち、「含んでいる」という用語は、「含んでいるがそれに限定されない」として解釈されるべきであり、「有する」という用語は、「少なくとも有する」として解釈されるべきであり、「含む」という用語は、「含むがそれに限定されない」として解釈されるべきである等）を意図することが当業者によって理解されるであろう。さらに、特定の数の導入された請求項の記述が意図される場合、そのような意図は請求項内で明示的に記述され、そのような記述が欠落する場合、そのような意図が全く存在しないことが当業者によって理解されるであろう。例えば、理解の支援として、以下の添付の請求項は、請求項の記述を導入するために、「少なくとも１つ」および「１つ以上」という導入語句の使用を含む場合がある。しかしながら、そのような語句の使用は、同じ請求項が「１つ以上」または「少なくとも１つ」という導入語句、および「１つ」（「ａ」または「ａｎ」）等の不定冠詞を含む場合であっても、「１つ」（「ａ」または「ａｎ」）という不定冠詞による請求項の記述の導入は、そのように導入された請求項の記述を含む任意の請求項が、１つだけのそのような記述を含む発明に限定することを暗示すると、解釈されてはならず（「ａ」および／または「ａｎ」は典型的に、「少なくとも１つ」または「１つ以上」と解釈される）、同じことは、請求項の記述を導入するために使用される定冠詞の使用にも言える。加えて、特定の数の導入された請求項の記載が明示的に記載される場合であっても、当業者は、そのような記載は典型的に、少なくとも記述された数を意味すると解釈されるべきである（すなわち、他の修飾語なく、「２つの記述」のみの記述は、典型的に、少なくとも２つの記述、または２つ以上の記述を意味する）。
したがって、本発明は、添付の請求項によることを除いて、限定されない。

Claims (8)

  1. 動的なテンプレートベースの特化を実装するためのコンピュータによって実装される方法であって、前記方法は、
    関数を提供することであって、前記関数は、動的なテンプレートパラメータの値の元を検証し、複数の分岐のうちテンプレートパラメータの値に対応するどの分岐を実行するかを決定する、ことと、
    前記関数を関数テンプレートに変換することであって、前記テンプレートのインスタンス化は、前記テンプレートパラメータとして指定される変数を必要とする、ことと、
    前記関数テンプレートを前記関数の複数のバージョンにコンパイルすることであって、各バージョンは、前記複数の分岐のうちの特定の１つに対応する、ことと、
    実行時に、前記テンプレートパラメータとして前記動的なテンプレートパラメータの値の元を含む関数起動文を介して変数を提供することと、
    前記変数を前記関数の正しいバージョンにマッピングすることと、
    実行時に、前記関数の前記正しいバージョンを起動することと
    を含む、コンピュータによって実装される方法。
  2. 前記変数は、コンパイル時定数ではないが、実行時不変量である、請求項１に記載のコンピュータによって実装される方法。
  3. 前記変数は、テンプレートパラメータの値の元を表す、請求項１に記載のコンピュータによって実装される方法。
  4. 前記動的なテンプレートパラメータは、構文注釈によって示されている、請求項１に記載のコンピュータによって実装される方法。
  5. 前記テンプレート化された関数の複数のバージョンの生成は、静的手法、動的手法、ハイブリッド手法のうちの少なくとも１つをさらに含む、請求項１〜３のいずれかに記載のコンピュータによって実装される方法。
  6. 前記ハイブリッド手法を用いる前記テンプレート化された関数に対する実行可能なコードの生成のために、プロファイルガイド解析が、前記複数の分岐のうち頻繁に実行される少なくとも１つの分岐を識別するために用いられる、請求項４に記載のコンピュータによって実装される方法。
  7. 前記関数を前記関数テンプレートに変換することは、関数を動的なテンプレート関数に変換することをさらに含み、前記動的なテンプレートのコンパイル中、前記動的なテンプレートパラメータに関連付けられた少数の値がある場合には、前記動的なテンプレートの全てのバージョンがコンパイラによって静的に生成される、請求項１〜６のいずれかに記載のコンピュータによって実装される方法。
  8. 前記関数を関数テンプレートに変換することは、関数を動的なテンプレート関数に変換することをさらに含み、特定のテンプレートパラメータの値に基づく前記動的なテンプレートのコンパイル中、前記テンプレート化された関数が起動される場合に、前記動的なテンプレートパラメータに関連付けられた多数の値がある場合には、前記テンプレート化された関数が起動されると、前記動的なテンプレートの特定のバージョンがコンパイラによって動的に生成される、請求項１〜６のいずれかに記載のコンピュータによって実装される方法。
JP2017206276A 2011-12-23 2017-10-25 データベース管理システムにおけるマイクロ特化の方法 Active JP6491725B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161630993P 2011-12-23 2011-12-23
US61/630,993 2011-12-23

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2014548980A Division JP6234935B2 (ja) 2011-12-23 2012-12-21 データベース管理システムにおけるマイクロ特化の方法

Publications (2)

Publication Number Publication Date
JP2018014142A true JP2018014142A (ja) 2018-01-25
JP6491725B2 JP6491725B2 (ja) 2019-03-27

Family

ID=48669580

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2014548980A Expired - Fee Related JP6234935B2 (ja) 2011-12-23 2012-12-21 データベース管理システムにおけるマイクロ特化の方法
JP2017206276A Active JP6491725B2 (ja) 2011-12-23 2017-10-25 データベース管理システムにおけるマイクロ特化の方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2014548980A Expired - Fee Related JP6234935B2 (ja) 2011-12-23 2012-12-21 データベース管理システムにおけるマイクロ特化の方法

Country Status (6)

Country Link
US (1) US9607017B2 (ja)
EP (1) EP2795484A4 (ja)
JP (2) JP6234935B2 (ja)
CA (1) CA2860223C (ja)
IN (1) IN2014DN05723A (ja)
WO (1) WO2013096894A1 (ja)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9389982B2 (en) 2011-04-18 2016-07-12 Sap Se Method and apparatus for monitoring an in-memory computer system
US9607017B2 (en) 2011-12-23 2017-03-28 The Arizona Board Of Regents On Behalf Of The University Of Arizona Methods of micro-specialization in database management systems
US10365900B2 (en) 2011-12-23 2019-07-30 Dataware Ventures, Llc Broadening field specialization
US9122523B2 (en) * 2012-05-03 2015-09-01 Nec Laboratories America, Inc. Automatic pipelining framework for heterogeneous parallel computing systems
EP2901285B1 (en) * 2012-09-28 2020-12-02 Sqream Technologies Ltd A system and a method for executing sql basic operators on compressed data without decompression process
CN105683940A (zh) * 2013-06-24 2016-06-15 惠普发展公司，有限责任合伙企业 处理混合流的数据流图
US11068796B2 (en) * 2013-11-01 2021-07-20 International Business Machines Corporation Pruning process execution logs
US20150123801A1 (en) * 2013-11-01 2015-05-07 Eltopia Communications, LLC Monitoring the state of a beehive
US10120902B2 (en) * 2014-02-20 2018-11-06 Citus Data Bilgi Islemleri Ticaret A.S. Apparatus and method for processing distributed relational algebra operators in a distributed database
US10025602B2 (en) * 2014-06-03 2018-07-17 Mentor Graphics Corporation Prelinked embedding
DE102014009594A1 (de) 2014-06-27 2015-12-31 Audi Ag Beleuchtungseinrichtung für ein Kraftfahrzeug mit einer Sicherheitseinrichtung zur Detektion von Fehlzuständen und Verfahren zur Detektion von Fehlerzuständen
WO2016011677A1 (en) 2014-07-25 2016-01-28 Hewlett-Packard Development Company, L.P. Local database cache
GB2529860A (en) * 2014-09-04 2016-03-09 Ibm Method and device for guided keyword-based exploration of data
US10031934B2 (en) * 2014-09-30 2018-07-24 International Business Machines Corporation Deleting tuples using separate transaction identifier storage
CN107851003A (zh) * 2015-04-02 2018-03-27 数据仓库投资有限公司 用于改进程序性能的字段专业化系统和方法
US10346168B2 (en) 2015-06-26 2019-07-09 Microsoft Technology Licensing, Llc Decoupled processor instruction window and operand buffer
US9720693B2 (en) * 2015-06-26 2017-08-01 Microsoft Technology Licensing, Llc Bulk allocation of instruction blocks to a processor instruction window
US10459916B2 (en) * 2015-07-31 2019-10-29 International Business Machines Corporation Updating database statistics during query execution
CN106649412B (zh) * 2015-11-04 2021-05-04 阿里巴巴集团控股有限公司 一种数据处理方法和设备
CN108369500A (zh) * 2015-12-14 2018-08-03 数据仓库投资有限公司 扩展字段专业化
US10733099B2 (en) 2015-12-14 2020-08-04 Arizona Board Of Regents On Behalf Of The University Of Arizona Broadening field specialization
US10503481B2 (en) * 2015-12-16 2019-12-10 Sybase, Inc. Generating a native access plan for dynamic entity calling
US9396248B1 (en) * 2016-01-04 2016-07-19 International Business Machines Corporation Modified data query function instantiations
US11704589B1 (en) * 2017-03-20 2023-07-18 Amazon Technologies, Inc. Automatically identifying dynamic applications
US12045653B2 (en) * 2017-06-22 2024-07-23 Dataware Ventures, Llc Field specialization to reduce memory-access stalls and allocation requests in data-intensive applications
US10891114B2 (en) 2017-08-17 2021-01-12 Tibco Software Inc. Interpreter for interpreting a data model algorithm and creating a data schema
CN110580241B (zh) * 2018-05-22 2023-09-01 微软技术许可有限责任公司 对索引文件进行预热
US10691304B1 (en) 2018-10-22 2020-06-23 Tableau Software, Inc. Data preparation user interface with conglomerate heterogeneous process flow elements
US11250032B1 (en) 2018-10-22 2022-02-15 Tableau Software, Inc. Data preparation user interface with conditional remapping of data values
US10977244B2 (en) 2018-11-06 2021-04-13 Snowflake Inc. Tracking intermediate changes in database data
US11275565B2 (en) 2018-11-21 2022-03-15 Kony, Inc. System and method for connecting end-users to business systems
AU2020100309B4 (en) 2019-03-20 2020-09-24 Parametric Systems Pty Ltd Techniques for Controlling Interaction with an Application Database
US11650982B2 (en) * 2019-04-01 2023-05-16 Sap Se Automatic selection of precompiled or code-generated operator variants
US11409520B2 (en) * 2019-07-15 2022-08-09 Sap Se Custom term unification for analytical usage
US11347736B2 (en) 2019-10-30 2022-05-31 Boray Data Technology Co. Ltd. Dynamic query optimization
WO2021087153A1 (en) * 2019-10-30 2021-05-06 Boray Data Technology Co. Ltd. Dynamic query optimization
US11334829B2 (en) * 2019-12-19 2022-05-17 Honeywell International Inc. Methods and systems for electronic checklist data references
CN111258557B (zh) * 2020-01-16 2023-08-18 Oppo（重庆）智能科技有限公司 代码处理方法、装置、电子设备及计算机可读介质
US11176138B2 (en) * 2020-02-25 2021-11-16 Salesforce.Com, Inc. Caching techniques for query runtime state
CN111400297B (zh) * 2020-03-19 2023-11-03 上海德拓信息技术股份有限公司 基于Hadoop的海量数据数据质量校验方法
US11755970B2 (en) * 2020-04-30 2023-09-12 Bfs Operations Llc Systems and methods for generating construction assignment schedules having multi-task construction projects
US11941560B2 (en) 2020-09-02 2024-03-26 Bfs Operations Llc Systems and methods for generating construction models for construction projects
US11153408B1 (en) 2021-01-29 2021-10-19 Salesforce.Com, Inc. Dependency management for shared data objects in a database system
WO2023272567A1 (en) * 2021-06-30 2023-01-05 Huawei Technologies Co., Ltd. Method and system for providing context-sensitive, non-intrusive data processing optimization framework
US12008363B1 (en) 2021-07-14 2024-06-11 International Business Machines Corporation Delivering portions of source code based on a stacked-layer framework
US12032994B1 (en) 2021-10-18 2024-07-09 Tableau Software, LLC Linking outputs for automatic execution of tasks
US11880365B2 (en) 2022-03-23 2024-01-23 Bank Of America Corporation Multimodal and distributed database system structured for dynamic latency reduction
CN115185526B (zh) * 2022-05-27 2023-10-10 韩济澎 一种能够逆向推理的编程语言的编译系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11161502A (ja) * 1997-09-09 1999-06-18 Sun Microsyst Inc スタティックオーバーロードのない基本型の値に関する効率的演算方法および装置
JP2000132408A (ja) * 1998-10-21 2000-05-12 Fujitsu Ltd コンピュ―タア―キテクチャエミュレ―ションシステム
JP2003202994A (ja) * 2001-10-31 2003-07-18 Matsushita Electric Ind Co Ltd Ｊａｖａコンパイラ、及び、当該Ｊａｖａコンパイラが使用するコンパイル情報の生成装置
US20030200537A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Apparatus and method for using database knowledge to optimize a computer program

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL100986A (en) * 1991-02-27 1997-01-10 Digital Equipment Corp Method for compiling code
JPH06180717A (ja) * 1992-12-14 1994-06-28 Hitachi Ltd データベース検索方式
JP3317825B2 (ja) 1995-09-28 2002-08-26 富士通株式会社 ループ最適化翻訳処理方法
US5787418A (en) * 1996-09-03 1998-07-28 International Business Machine Corporation Find assistant for creating database queries
US5842209A (en) * 1996-09-03 1998-11-24 International Business Machines Corporation User interface for visually depicting inner/outer/left/right joins in a database system
US6622300B1 (en) 1999-04-21 2003-09-16 Hewlett-Packard Development Company, L.P. Dynamic optimization of computer programs using code-rewriting kernal module
US6539374B2 (en) * 1999-06-03 2003-03-25 Microsoft Corporation Methods, apparatus and data structures for providing a uniform representation of various types of information
JP2002073387A (ja) * 2000-08-25 2002-03-12 Ricoh Co Ltd データベース処理方法
US7131119B2 (en) * 2001-05-30 2006-10-31 International Business Machines Corporation Code optimization
US6931395B2 (en) * 2001-10-25 2005-08-16 International Business Machines Corporation Method and apparatus for optimizing queries in a logically partitioned computer system
JP3813087B2 (ja) * 2001-12-20 2006-08-23 インターナショナル・ビジネス・マシーンズ・コーポレーション プログラム変換方法、コンピュータ装置及びプログラム
US20040243555A1 (en) * 2003-05-30 2004-12-02 Oracle International Corp. Methods and systems for optimizing queries through dynamic and autonomous database schema analysis
US7146352B2 (en) * 2003-06-23 2006-12-05 Microsoft Corporation Query optimizer system and method
US7447680B2 (en) * 2004-07-29 2008-11-04 International Business Machines Corporation Method and apparatus for optimizing execution of database queries containing user-defined functions
US7493602B2 (en) * 2005-05-02 2009-02-17 International Business Machines Corporation Methods and arrangements for unified program analysis
US7954094B2 (en) * 2006-03-27 2011-05-31 International Business Machines Corporation Method for improving performance of executable code
US20070239656A1 (en) * 2006-04-06 2007-10-11 Santosuosso John M Removal of Database Query Function Calls
US7877370B2 (en) * 2006-05-15 2011-01-25 Algebraix Data Corporation Systems and methods for data storage and retrieval using algebraic relations composed from query language statements
US7805456B2 (en) * 2007-02-05 2010-09-28 Microsoft Corporation Query pattern to enable type flow of element types
US8198899B2 (en) * 2009-03-16 2012-06-12 Pgs Geophysical As Method and system for calibrating streamer electrodes in a marine electromagnetic survey system
US9135405B2 (en) 2011-05-26 2015-09-15 Carnegie Mellon University Automated exploit generation
US8793240B2 (en) * 2011-08-26 2014-07-29 Oracle International Corporation Generation of machine code for a database statement by specialization of interpreter code
US9607017B2 (en) 2011-12-23 2017-03-28 The Arizona Board Of Regents On Behalf Of The University Of Arizona Methods of micro-specialization in database management systems
US9122523B2 (en) * 2012-05-03 2015-09-01 Nec Laboratories America, Inc. Automatic pipelining framework for heterogeneous parallel computing systems
US20140115001A1 (en) * 2012-10-19 2014-04-24 Playence GmBH Structured query generation
IN2013CH05115A (ja) * 2013-11-12 2015-05-29 Inmobi Pte Ltd

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11161502A (ja) * 1997-09-09 1999-06-18 Sun Microsyst Inc スタティックオーバーロードのない基本型の値に関する効率的演算方法および装置
US6085035A (en) * 1997-09-09 2000-07-04 Sun Microsystems, Inc. Method and apparatus for efficient operations on primary type values without static overloading
JP2000132408A (ja) * 1998-10-21 2000-05-12 Fujitsu Ltd コンピュ―タア―キテクチャエミュレ―ションシステム
US20020147969A1 (en) * 1998-10-21 2002-10-10 Richard A. Lethin Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method
JP2003202994A (ja) * 2001-10-31 2003-07-18 Matsushita Electric Ind Co Ltd Ｊａｖａコンパイラ、及び、当該Ｊａｖａコンパイラが使用するコンパイル情報の生成装置
US20030200537A1 (en) * 2002-04-18 2003-10-23 International Business Machines Corporation Apparatus and method for using database knowledge to optimize a computer program

Also Published As

Publication number Publication date
CA2860223C (en) 2017-09-19
IN2014DN05723A (ja) 2015-04-10
EP2795484A1 (en) 2014-10-29
US9607017B2 (en) 2017-03-28
EP2795484A4 (en) 2015-11-11
WO2013096894A1 (en) 2013-06-27
JP6234935B2 (ja) 2017-11-22
JP6491725B2 (ja) 2019-03-27
US20140365533A1 (en) 2014-12-11
JP2015507793A (ja) 2015-03-12
CA2860223A1 (en) 2013-06-27
WO2013096894A9 (en) 2013-11-21

Similar Documents

Publication Publication Date Title
JP6491725B2 (ja) データベース管理システムにおけるマイクロ特化の方法
Cheung et al. Sloth: Being lazy is a virtue (when issuing database queries)
Bacon et al. Spanner: Becoming a SQL system
Yang et al. How not to structure your database-backed web applications: a study of performance bugs in the wild
Gaffney et al. Sqlite: past, present, and future
US9361094B1 (en) Mining application repositories
Shaikhha et al. Building efficient query engines in a high-level language
Gupta et al. Aggify: Lifting the curse of cursor loops using custom aggregates
Zhang et al. Micro-specialization: dynamic code specialization of database management systems
Ramachandra et al. Program transformations for asynchronous and batched query submission
JP2018510445A (ja) プログラム性能を向上させる領域特化システムおよび方法
Zhang et al. Micro-specialization in DBMSes
US9766926B2 (en) Method and system for optimizing parallel program execution based on speculation that an object written to is not shared
Gruber et al. Bringing compiling databases to RISC architectures
Xu et al. Niijima: Sound and automated computation consolidation for efficient multilingual data-parallel pipelines
Rietveld et al. Reducing layered database applications to their essence through vertical integration
Shi et al. Towards unified ad-hoc data processing
Hadri et al. Software usage on Cray systems across three centers (NICS, ORNL and CSCS)
Makor et al. Automatic array transformation to columnar storage at run time
Dashti et al. Compiling database application programs
Zyulkyarov et al. Profiling and optimizing transactional memory applications
Hu et al. WeBridge: Synthesizing Stored Procedures for Large-Scale Real-World Web Applications
Lamb et al. Apache Arrow DataFusion: A Fast, Embeddable, Modular Analytic Query Engine
Rietveld et al. Re-engineering compiler transformations to outperform database query optimizers
Cheung Rethinking the application-database interface

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171025

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180831

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180905

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181204

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190129

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190205

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190301

R150 Certificate of patent or registration of utility model

Ref document number: 6491725

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250