[pgsql-jp: 41719] Re: union all時のSubquery Scanの処理内容とパフォーマンス改善について

Hiroki Kataoka kataoka @ interwiz.jp
2014年 9月 3日 (水) 01:34:27 JST


片岡です。

2300万行のSubquery
Scanをせざるを得ないのか、あるいは別の速いアプローチがあるのかどうかなどは、WHERE句による絞り込みがどこにあるのか?やJOINの条件などに大きく作用されますが、加藤さんの投稿はその部分が見事に欠落しています。ですから的確な回答を受けるのは難しいと思われます。

加藤さんは、必要十分な情報を提供されたとお思いかもしれませんが、その判断がご自分でできるならクエリーの最適化もご自分でできていたはず、という見方もできます。不足している情報を提供したところで目指す回答が得られる確証はありませんが、少なくとも現状では難しいと思います。MLを活用しスキルアップするためにも、前向きにお考えください(テーブル名やカラム名などは差し障りの無いものに変えればいいのです)。

> 結合までの処理で SharedBuffer にデータが載っている状態で
> さらにスキャンをしている、と理解しました。
> 無駄な処理のように思えてしまうのですが、そういうものなのでしょうか。

JOINした後に2つの結果をUNION ALLし、その後GROUP
BYしていますよね。JOINしただけでは目的の結果が得られないことは明らかです(UNION ALLのみで、GROUP BYやORDER
BYがなければ終わりにできるかもしれませんが)。もしかしたらJOIN条件がちょうどGROUP BYに合致するような条件(JOINがHASH
JOINではなくMARGE JOINが可能なシチュエーションで、さらにGROUP
BYも同じカラムをグルーピングすることを求めているなど)であればさらに最適化できる可能性もありますが、何しろその辺はクエリーやテーブルの特性などが省略されていて検討不可能です。

-- 
Hiroki Kataoka


pgsql-jp メーリングリストの案内