シンプルなルックアップクエリ、高速でのMySQL

Question

に私は昨日からこの上で私の頭を叩いてる、と私は何が起こっているかunderstanfません：

私は、datawarehousingプロジェクトの次元スキーマを移入使用しています基本的に次元表の既存の行を検索し、存在しないものを挿入して技術キーを返す、「次元検索/更新」を実行するためのPentahoケトル

ディメンションテーブル自体は非常に単純である：

CREATE TABLE dim_loan 
(
    _tech_id INTEGER NOT NULL, 

    loan_id INTEGER, 
    type TEXT, 
    interest_rate_type TEXT, 

    _dim_project_id integer, 

    _validity_from date, 
    _validity_to date, 
    _version integer, 

    PRIMARY KEY (_tech_id) 
); 
CREATE INDEX dim_loan_pk_idx ON dim_loan USING btree (_tech_id); 
CREATE INDEX dim_loan_compound_idx ON dim_loan USING btree (loan_id, _dim_project_id, _validity_from, _validity_to); 

表は、650Kの行の周りに、プロセスの終了時に、含有すべきです。変換は約1500行/秒で高速（ish）に開始されます。 テーブルのサイズが約50k行になるまでに、パフォーマンスは50行/秒に達するまで徐々に低下します。

もちろん

"Index Scan using dim_loan_compound_idx on dim_loan (cost=0.42..7.97 rows=1 width=42) (actual time=0.043..0.043 rows=0 loops=1)" 
" Index Cond: ((loan_id = 1) AND (_dim_project_id = 2) AND ('2016-01-01'::date >= _validity_from) AND ('2016-01-01'::date < _validity_to))" 
"Total runtime: 0.078 ms" 

実際の実行時間が10msのまわりに、大きく異なるが、受け入れられない：

SELECT _tech_id, _version, "type" AS "Loan Type", interest_rate_type AS int_rate, _validity_from, _validity_to FROM "public".dim_loan WHERE loan_id = $1 AND _dim_project_id = $2 AND $3 >= _validity_from AND $4 < _validity_to 

問い合わせプランナは、0.1ミリ秒の実行時間を推定：ケトルは次のようになりん クエリ。

Seq Scan on dim_loan (cost=0.00..2354.21 rows=12 width=52) 
      Filter: (($3 >= _validity_from) AND ($4 < _validity_to) AND (_dim_project_id = $2) AND ((loan_id)::double precision = $1)) 
< 2016-12-18 21:30:19.859 CET >LOG: duration: 14.260 ms plan: 
     Query Text: SELECT _tech_id, _version, "type" AS "Loan Type", interest_rate_type AS int_rate, _validity_from, _validity_to FROM "public".dim_loan WHERE loan_id = $1 AND _dim_project_id = $2 AND $3 >= _validity_from 
     AND $4 < _validity_to 

それだけではなく、ゆっくりと実行これらのクエリですが、それらのすべてとして、とにかく全体の話を教えていない：私はこのような高い頻度エントリを参照auto_explainとスロークエリログを有効にします。 もちろん、メモリのパラメータを微妙に変化させてパフォーマンスを上げようとしましたが、最新の9.6も試しましたが、これは9.3と同じ動作を示しています。

同じインデックスを持つMySQLデータベースの同じ変換は、開始から終了まで5000行/秒でうまく動作します。私は本当にPGを使用したいと思うし、それは何か自明であると確信していますが、何が！ jdbcドライバで何かがあるかもしれませんか？私はそれが常に1つの接続を使用することを確認したので、接続オーバーヘッドの問題でもありません...

Answer 1

実際には、原因が確かに貸し出しIDがダブルにキャストされていることがわかりました！理由は、このコラムのメタデータにケトル氏が間違っていたことを前提としています。 パフォーマンスはMySQLと同等です！幸せな日