2017-06-10 4 views
0

アマゾンRDSで実行中のpostgres 9.6。キャンペーンの定義と小さなテーブル - - 6つのキー(IDS) Postgresの計画は実行に無駄な時間がかかります

  • キャンペーンのメタデータを持つ大きなテーブル

    1. 集約イベント:

      は、私は2つのテーブルを持っています。

    キャンペーン名のようなメタデータをフィルタリングするために2に参加します。

    クエリは、キャンペーンのチャンネルと日付別に表示される内訳のレポートを取得するためのものです(日付は毎日です)。

    いいえFKといい、nullではありません。レポートテーブルにはキャンペーンごとに1日に複数の行があります(アグリゲーションは6つの属性キーに基づいているため)。

    私が参加し、クエリプランは、(300ミリ秒対)10Sに成長

    explain analyze select c.campaign_channel as channel,date as day , sum(displayed) as displayed 
    from report_campaigns c 
    left join events_daily r on r.campaign_id = c.c_id 
    where provider_id = 7726 and c.p_id = 7726 and c.campaign_name <> 'test' 
    and date >= '20170513 12:00' and date <= '20170515 12:00' 
    group by c.campaign_channel,date; 
                             QUERY PLAN 
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
    GroupAggregate (cost=71461.93..71466.51 rows=229 width=22) (actual time=104.189..114.788 rows=6 loops=1) 
        Group Key: c.campaign_channel, r.date 
        -> Sort (cost=71461.93..71462.51 rows=229 width=18) (actual time=100.263..106.402 rows=31205 loops=1) 
         Sort Key: c.campaign_channel, r.date 
         Sort Method: quicksort Memory: 3206kB 
         -> Hash Join (cost=1092.52..71452.96 rows=229 width=18) (actual time=22.149..86.955 rows=31205 loops=1) 
           Hash Cond: (r.campaign_id = c.c_id) 
           -> Append (cost=0.00..70245.84 rows=29948 width=20) (actual time=21.318..71.315 rows=31205 loops=1) 
            -> Seq Scan on events_daily r (cost=0.00..0.00 rows=1 width=20) (actual time=0.005..0.005 rows=0 loops=1) 
              Filter: ((date >= '2017-05-13 12:00:00'::timestamp without time zone) AND (date <= '2017-05-15 12:00:00'::timestamp without time zone) AND (provider_id = 
            -> Bitmap Heap Scan on events_daily_20170513 r_1 (cost=685.36..23913.63 rows=1 width=20) (actual time=17.230..17.230 rows=0 loops=1) 
              Recheck Cond: (provider_id = 7726) 
              Filter: ((date >= '2017-05-13 12:00:00'::timestamp without time zone) AND (date <= '2017-05-15 12:00:00'::timestamp without time zone)) 
              Rows Removed by Filter: 13769 
              Heap Blocks: exact=10276 
              -> Bitmap Index Scan on events_daily_20170513_full_idx (cost=0.00..685.36 rows=14525 width=0) (actual time=2.356..2.356 rows=13769 loops=1) 
               Index Cond: (provider_id = 7726) 
            -> Bitmap Heap Scan on events_daily_20170514 r_2 (cost=689.08..22203.52 rows=14537 width=20) (actual time=4.082..21.389 rows=15281 loops=1) 
              Recheck Cond: (provider_id = 7726) 
              Filter: ((date >= '2017-05-13 12:00:00'::timestamp without time zone) AND (date <= '2017-05-15 12:00:00'::timestamp without time zone)) 
              Heap Blocks: exact=10490 
              -> Bitmap Index Scan on events_daily_20170514_full_idx (cost=0.00..685.45 rows=14537 width=0) (actual time=2.428..2.428 rows=15281 loops=1) 
               Index Cond: (provider_id = 7726) 
            -> Bitmap Heap Scan on events_daily_20170515 r_3 (cost=731.84..24128.69 rows=15409 width=20) (actual time=4.297..22.662 rows=15924 loops=1) 
              Recheck Cond: (provider_id = 7726) 
              Filter: ((date >= '2017-05-13 12:00:00'::timestamp without time zone) AND (date <= '2017-05-15 12:00:00'::timestamp without time zone)) 
              Heap Blocks: exact=11318 
              -> Bitmap Index Scan on events_daily_20170515_full_idx (cost=0.00..727.99 rows=15409 width=0) (actual time=2.506..2.506 rows=15924 loops=1) 
               Index Cond: (provider_id = 7726) 
           -> Hash (cost=1085.35..1085.35 rows=574 width=14) (actual time=0.815..0.815 rows=582 loops=1) 
            Buckets: 1024 Batches: 1 Memory Usage: 37kB 
            -> Bitmap Heap Scan on report_campaigns c (cost=12.76..1085.35 rows=574 width=14) (actual time=0.090..0.627 rows=582 loops=1) 
              Recheck Cond: (p_id = 7726) 
              Filter: ((campaign_name)::text <> 'test'::text) 
              Heap Blocks: exact=240 
              -> Bitmap Index Scan on report_campaigns_provider_id (cost=0.00..12.62 rows=577 width=0) (actual time=0.062..0.062 rows=582 loops=1) 
               Index Cond: (p_id = 7726) 
    Planning time: 9651.605 ms 
    Execution time: 115.092 ms 
    
    
    result: 
    channel |   day   | displayed 
    ----------+---------------------+----------- 
    Pin  | 2017-05-14 00:00:00 | 43434 
    Pin  | 2017-05-15 00:00:00 | 3325325235 
    
  • +1

    結合されたテーブルのテーブルスキーマ、その制約(ユニーク、主キーなど)を投稿してください。クエリーが平易な英語の単語で達成するはずのことを記述してください(それを書く別の方法があるかもしれません)。ヌルになる列はどれですか? nullは、通常、ゼロ対1またはゼロ対多関係を意味します。 NULLの代わりに外部キー制約を使用するのはどうですか?機能的な依存関係は何ですか?テーブルは3番目の正規形ですか? 'date_trunc( 'day'、date)'にインデックスがありますか?可能であれば、3つのテーブルのジョインの前後にいくつかの行のサンプルデータを投稿してください。未使用の列は忘れてしまいます。 – flutter

    +0

    データを追加してクエリを簡素化しました。 FKとNULLについての説明と情報が必要な理由を理解できません。 あまりにも多くのデータを追加すると、質問を読むのが難しくなります。 クエリプランのすべての重要な情報が表示されます。インデックスを見ることができます。 –

    +1

    Postgresメーリングリストに投稿したほうが、より良い返答を得るでしょう。私はPostgresの開発者が非常に興味があると確信しています。 –

    答えて

    0

    私は、これは左参加する前に事前計算を強制するために合計である私には思えます。

    解決策は、左結合および合計の前に2つのネストされたサブSELECTにWHERE句をフィルタリングすることでした。

    ・ホープ、この作品:

    SELECT channel, day, sum(displayed) 
    FROM 
    (SELECT campaign_channel AS channel, date AS day, displayed, p_id AS c_id 
    FROM report_campaigns WHERE p_id = 7726 AND campaign_name <> 'test' AND date >= '20170513 12:00' AND date <= '20170515 12:00') AS c, 
    (SELECT * FROM events_daily WHERE campaign_id = 7726) AS r 
    LEFT JOIN r.campaign_id = c.c_id 
    GROUP BY channel, day; 
    
    +0

    サブセレクトは動作しますが、サブレポートを使用したくないのは、レポートエンジンをより複雑にするためです(実際のクエリは複雑になり、テーブルはほとんど含まれていません)。 –

    +0

    おそらく1つの解決策は、合計を削除し、クエリ全体を単一のサブクエリとして実行し、最終結果を合計することです。また、主キーと索引付けをしていますか? – SaintNazaire

    +0

    申し訳ありません。 usa_events =>説明を分析するselect campaign_id、events_dailyからの支出rはr.campaign_id = c.c_idのreport_campaigns cに残されます。date> = '20170720'とdate <'20170721'; 計画時間:8393.337 ms 実行時間:0。132 ms (11 rows) –

    関連する問題