昨日の友は今日の敵？・・・・狭いね、この業界も！ ＃２ Tweet

前回、
＞ん〜〜。どんな問題が発生しているのか？　書きたいとは思うがそれはまた後日。

と書いたのでその続きでも。

今回ポイントとなっているのは、

「コストベースオプティマイザに対応しました。」

のような言葉をどう受け取るか？　というところ。

この　「対応しました」　ってのがくせ者だったんですよね今回は。ちゃんとしているところなら、readme.txtなり、リリースノートなり、新機能概要　などに　なにをどう対応した等、しっかりと内容が記載されているのですが、それが無かったのですよ。
なにをどう対応したのか不明確なので、利用するユーザも勝ってな思い込みで良い方に受け取ってしまうこともあるわけですね。（今回は、ある程度疑っていたようですが・・・）

ルールベースオプティマイザでチューニングされていた製品が、コストベースオプティマイザに対応しました。　ということで、アップデートされたと思ってください。
（もし、これだけしか記載されていないとしたら、どのように対応したのか不明なままです）

ユーザ側は、リリースされた製品は、コストベースオプティマイザに最適化されたSQLを実装していると思ってしまう　”可能性”　があるわけです。
リリースノートには、「コストベースオプティマイザに対応しました」　とだけしか書いてないので、「コストベースオプティマイザでの動作を確認しただけ」　と受け取れる内容であるにも関わらず。。

リリースされた製品を使い、ユーザ側で性能テストなどを行っていくうちに、前より遅くない？　という状況に気付き始める。
動作確認をしただけ、または、それに近い状況であれば、ルールベースで最適化されたSQLは、コストベースオプティマイザに最適化されていないため、ルールベースの時よりもアクセスパスが悪くなり、なんじゃこりゃっていう結果になっているSQL文が幾つか存在していることに、初めて気付くのである。

当然、騒ぎになり、SQLトレースなど取ってみると、表のFull Scanは多発しているは、　表のFull Scan同士で結合されている。運悪く１千万件近くある巨大な表だったりして、　あららららら〜っ、という状況になっていることが証拠として提出されることになる。

そして、
「動作を確認しただけ」　もしくは、それにかなり近い状況であることが、ユーザサイドで認識されることとなったわけです。

さて、ここからが、大変だ。
「エブリシングお見通しでい〜〜。」　ってノリで、　ユーザが製品開発元に改善を求めることになるわけですから。

ただ、エンドユーザ側でも、
「コストベースオプティマイザに対応しました」　というだけで、その詳細が記載されていないと気付いた時点で、怪しいと考え、「どこをどう対応したのか」具体的な資料や解説を求める、または、差し戻すなりしておけば、無駄な性能テストで休出することも、夜遅くまで評価テストする必要も無かったと思うのですがね。