[pgsql-jp: 29527] Re: INSERTの速度UP に関して

[Tadashi Kanbayashi]

杉田様
お疲れさまです。

アドバイスありがとうございます。
KANです。

>   杉田です。
>
> ;;; しかし、文法的に正しいのでしょうか？
>
>   文法的には、いいのではないですか？ 行うことが変わらないので、処理時間は
変わ
> らないです。
>
> ;;; どうもJOINの書き方がプランナを混乱させている気がするのですが？。
>
>   どう混乱しているのでしょう？ 同じことをして同じだけの時間がかかっている
ので
> はないのですか？
>

複数テーブルのJOINは、括弧で囲まれた一群を１つのテーブルとみなして結合する
と理解していました。
括弧で囲まないもの同士、JOINの羅列でも文法としては正しいのですね。

プランナが、むりくりJOINを理解しようとして、その結果、実行計画がわるくなっ
ているのではと
思いました。

プランナとしては、どちらでも良い、かわらないということですね。

> ;;; とりあえず、JOINを使わないようにすると約３分で結果が返ってくるので、
> ;;; JOINを使わないSQLに書き換えようと思いますが、それでも約３分かかりま
す。
> ;;; INDEXをはること以外で、何か策はないでしょうか。
>
>   まずは、EXPLAIN/EXPLAIN ANALYZE して、インデックス使用などでプランに改
善の余
> 地があるかを考えるのがいいんじゃないでしょうか？
>

INDEXスキャンをするようにSQLを改善していくのが良いでしょうか。
SEAQスキャンをなくせるかどうかを、まだ改善の余地があるかどうか
の目安にするで良いでしょうか。

> ;;; テーブル結合の処理の高速化としては、
> ;;; (1)プランナ任せ（コストベース）
> ;;; (2)INDEXの追加
> ;;; (３)JOINで結合手順を強制的にいじる（ルールベース）
> ;;; で行ない、それでもだめそうな場合は、SQLを分割（処理をわける）すること
が必要
> ;;; でしょうか。
>
>   (3) は、優先順位を下げたい気がします。
>
>   さらに、単独のクエリーでの改善で突き当たったら、そのクエリーを含む処理
全体の
> 見直し、テーブル設計の見直し、アプリ ケーション側の努力というのもありそう
です。
>

何がなんでも１つのSQLで処理を完結させるという設計姿勢は良くないですよね？

> ;;; どんなSQLでも、高速化の限界はあると思いますが、そのときの目安（閾値）
が
> ;;; あれば教えていただきたく。
> ;;;
> ;;; ちなみに、結合しているテーブルの規模は以下の通りです。
> ;;; t_cidinf：6990
> ;;; t_contopen：50679
> ;;; t_cpinf：130
> ;;; t_cpshare：248
> ;;; t_miminf：249
> ;;; t_payinf：102
> ;;; t_tidinf：295
> ;;; t_paycid：3271
> ;;; t_paycidgroup：6986
> ;;; t_hanroinf：21
> ;;; t_shimebi：80
> ;;; t_bill_detail：150548
>
>   クエリーがどのようなものになるか分からないので、典型的なクエリーを用意
して、
> 検証するのがいいと思えます。
>

いろいろ検証してみます。
チューニングを前提にしすぎているというか、
ある程度はパフォーマンスを考慮して開発を進めていれば
こうはならないのにと思いつつ、　開発しなおしは難しいので、もう少しがんばっ
てみます。

ありがとうございます。

>
> Kenji Sugita
>


---
T.Kan