2016-09-05 9 views
0

は、私は、クエリへの「サブ選択」クエリに問題があります。私は、クエリを説明するためにpgAdminでを使用して、彼は私にこのメッセージを表示します。スロークエリpostgreSQLの

"Group (cost=7029.62..651968.20 rows=17843 width=27) (actual time=431.017..4513.973 rows=11483 loops=1)" 
" Buffers: shared hit=139498 read=411, temp read=255 written=255" 
" -> Sort (cost=7029.62..7074.90 rows=18111 width=27) (actual time=430.630..667.098 rows=54660 loops=1)" 
"  Sort Key: ((f."timestamp")::date), f.user_id, f.activity_type, f.container_id" 
"  Sort Method: external merge Disk: 2008kB" 
"  Buffers: shared hit=1702 read=411, temp read=255 written=255" 
"  -> Seq Scan on fact_activity f (cost=0.00..5748.76 rows=18111 width=27) (actual time=0.107..188.827 rows=54660 loops=1)" 
"    Filter: ((container_type ~~ '700'::text) AND (("timestamp")::date < to_date('2016-09-05'::text, 'YYYY-MM-DD'::text)))" 
"    Rows Removed by Filter: 125414" 
"    Buffers: shared hit=1691 read=411" 
" SubPlan 1" 
" -> Aggregate (cost=36.12..36.13 rows=1 width=5) (actual time=0.315..0.318 rows=1 loops=11483)" 
"   Buffers: shared hit=137796" 
"   -> Seq Scan on users_groups_copy g (cost=0.00..36.09 rows=11 width=5) (actual time=0.041..0.266 rows=13 loops=11483)" 
"    Filter: ((state ~~ 'owner'::text) AND (place_id = f.container_id))" 
"    Rows Removed by Filter: 1593" 
"    Buffers: shared hit=137796" 
"Total runtime: 4536.074 ms" 

はまた、私はテーブルを結合しようとしたが、要求が道よりこのような、遅い:最後に

select 
f.timestamp::date as date, 
    user_id, 
    activity_type, 
    f.container_id as group_id, 
    string_agg(distinct("userId"), ',') as group_owners 
from 
    fact_activity f 
join jusers_groups_copy g 
on g.place_id = f.container_id 
where 
    f.container_type like '700' 
    and f.timestamp::date < to_date('2016-09-05', 'YYYY-MM-DD') 
    and g.state like 'owner' 
group by 
    date, user_id, activity_type, group_id 
order by 
    date, user_id, activity_type, group_id 

、そこにこのデータベースへのインデックスです。それがなぜそのリクエストが遅いのですか?

このリクエストを改善する方法を知りたいと思います。事前

+0

は、「ある」されます「ない」とは何ですか? – montewhizdoh

+1

これは主な理由ではありませんが、 "like"をワイルドカードなしで使用する理由はありません:f.container_type like '700' – montewhizdoh

+2

'fact_activity(container_type、timestamp)'のインデックスを試し、 'container_type = 'と' f.timestamp

答えて

1

おかげでクエリを変更することなく、最大のパフォーマンスの改善が副選択をスピードアップ副選択で、テーブル上のインデックスのようになります。

CREATE INDEX nice_name ON jusers_groups_copy(place_id, state text_pattern_ops); 

しかし、私のようにクエリを書き換えます参加する。そうすれば、データに応じてネストされたループよりも効率的なものが得られるかもしれません。

の代わりにあなたが選択した参加型に依存し

SELECT f.somecol, g.othercol 
FROM fact_activity f 
    JOIN jusers_groups_copy g 
     ON g.place_id = f.container_id 
WHERE g.state LIKE 'owner' 
    AND ...; 

を書くべき

SELECT f.somecol, 
    (SELECT g.othercol 
    FROM jusers_groups_copy g 
    WHERE g.place_id = f.container_id 
     AND g.state LIKE 'owner') 
FROM fact_activity f 
WHERE ...; 

、インデックス(ネストされたループの場合)上記または別のインデックスは、そのクエリを高速に行うことができます。

0

私はあなたが私が最も重要なparametresを考えて、次のWebサイト

pgtune

を使用/data/postgresql.conf にいくつかの設定を変更する必要があると思います「work_mem」が

関連する問題