● パイプライン 機能は更新 （UPDATE） の パフォーマンス を高める技術である。

　論理 I/O （プログラム が出す I/O） を削減するために、パイプライン 機能 （pipeline） を搭載している RDB もある。
　パイプライン 機能とは、多数の論理 I/O を メモリー・バッファ のなかに ホールド しておき、1 回の物理 I/O （EXCP） に変換する機能である。したがって、更新 （UPDATE） 用の技巧であって、読み込み （READ） には適用されない。

　パイプライン 機能は 「非同期更新」 の一種であるが、トランザクション 単位に更新する パフォーマンス に比べても、ほとんど、タイムラグ を置かない更新であり、複数の更新 トランザクション を 1 回の物理 I/O で済ますのだから、パフォーマンス は良い。通常、100 回の論理 I/O を 1 回の物理 I/O に変換するが、100 という数値は変更することができる。

　
● パイプライン 機能の数値を大きくすればするほど、パフォーマンス が良くなる訳ではない。

　100 という数値を高くすればするほど、メモリー のなかで ホールド する タイムラグ が大きくなるし、ログ・ファイル に対する書き込み （ログ・ファイル の大きさ） も考慮しなければならないので、数値を大きくすればするほど パフォーマンス が良くなるという訳ではない。
　パイプライン の パラメータ の最適値は どのくらいなのかを述べることは、システム の環境 （CPU のつよさ、メモリー の大きさ、ディスク の数など） にもよるので一概に述べることはできないが、300 から 500 が無難な上限値である、と思う。

　当然ながら、メモリー のなかに ホールド する数値に達する以前に、ジョブ が終了したり、ログ・ファイル の スピル （spill） が実行されたなら、ホールド の数値に達していなくても、パイプライン 機能は完結して、ログ・ファイル、データ・ファイル および インデックス・ファイル に対して、順次、書き込みがおこなわれる （ちなみに、書き込みの順序に注意されたい）。

　メモリー のなかに ホールド する トランザクション の数が増えれば増えるほど、停電 （あるいは、瞬停、電圧の変動など） に対する危険性が高くなるので、無停電装置を導入していないのであれば、パイプライン 機能をむやみに使うのは危険である。

　
● 「ADD-only」 に対して パイプライン 機能を使えば、高 パフォーマンス を実現できる。

　パイプライン 機能を搭載した RDB を使うときに考慮したい点は、「更新 （UPDATE） の パフォーマンス を高める パラメータ は用意されているが、読み込み （READ） の パフォーマンス を高める パラメータ はない」という点である。
　しかも、更新のなかで、ADD が論理 I/O 回数が少ない、という点である。