一応、修正前後の2.5αで比較した範囲では、MY/PG双方共に速度的には少なからず改善はしているので取りあえずは「よし」だとは思っています。(さらにSC_Queryの調整結果により低スペ環境での動作は相当改善しているはず。）

DB個別分岐によるチューニングは、大幅な改善の方策をする場合かなり大規模な分岐を要するため、今後の足かせになる＆開発労力が必要なのと、今回の要件でも分岐は各処理には書かずDBFactoryにまとめると、たしかあったと思いますので、それもネックになる感じです。
2.5で商品一覧生成がlfDispProductsListとSC_Productの組合せ動作が要求されている中で、さらにDBFactoryにも行ったり来たりだと、カスタマイズのボトルネックにもなりますね・・・。

分岐させるとした場合、クエリの全体構造をMySQL向けには全面変更する感じが最高速になるのは分かっていて、案として頭にはありますが、SC_Productの全面分岐や、MySQL専用テーブル作成なんて事態になりそうな案だったり（苦笑
やりきればPostgreSQL並に近づくでしょう。
※個人的に最近の仕事ではPostgreSQLが9割以上なんで、MySQL EC-CUBEにモチベーションが上がらないというのもあります

INSERT時処理についてですが、昨日のコミットでSC_QueryのINSERT/UPDATE/DELETE（DML)関連は少し高速化と軽量化を図ってみました。もう少し手のつけようがありますが、少しは性能改善したかなと。特に数回実行する処理があった場合は大幅に変わったはずです。
DB周りは得意ジャンルなんで一応トランザクション的処理周りについては後日ゆっくりみたいなとは思っています（たぶん年末ギリギリかな・・・）。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h