1

Amazon RDS db.r3.4xlarge インスタンス (16CPU、122GB メモリ) で Postgres 9.4.4 を実行しています。私は最近、大規模なテーブル (〜 2 億 7000 万レコード) でかなり単純な集計を必要とするクエリの 1 つに出くわしました。クエリの実行には 5 時間以上かかります。

大きなテーブルの結合列とグループ化列には、インデックスが定義されています。work_memとtemp_buffersをそれぞれ1GBに設定して実験してみましたが、あまり役に立ちません。

これがクエリと実行計画です。どんなリードも高く評価されます。

explain SELECT
largetable.column_group,
MAX(largetable.event_captured_dt) AS last_open_date,
.....   

FROM largetable

LEFT JOIN smalltable
ON smalltable.column_b = largetable.column_a

WHERE largetable.column_group IS NOT NULL

GROUP BY largetable.column_group

これが実行計画です -

GroupAggregate  (cost=699299968.28..954348399.96 rows=685311 width=38)
  Group Key: largetable.column_group
  ->  Sort  (cost=699299968.28..707801354.23 rows=3400554381 width=38)
        Sort Key: largetable.column_group
        ->  Merge Left Join  (cost=25512.78..67955201.22 rows=3400554381 width=38)
              Merge Cond: (largetable.column_a = smalltable.column_b)
              ->  Index Scan using xcrmstg_largetable_launch_id on largetable  (cost=0.57..16241746.24 rows=271850823 width=34)
                    Filter: (column_a IS NOT NULL)
              ->  Sort  (cost=25512.21..26127.21 rows=246000 width=4)
                    Sort Key: smalltable.column_b
                    ->  Seq Scan on smalltable  (cost=0.00..3485.00 rows=246000 width=4)
4

1 に答える 1

1

大きなテーブルの結合キーとグループ化キーにはインデックスが付けられていると言いますが、小さなテーブルの結合キーについては言及していません。

マージとソートは速度低下の大きな原因です。ただし、〜 700,000 行のデータを返すことも心配しています。それはあなたにとって本当に役に立ちますか？それだけの量のデータを返す必要があるのに、5 時間待つのは長すぎるという状況はどのようなものでしょうか? すべてのデータを出力する必要がない場合は、できるだけ早くフィルタリングすることが、実現する速度の大幅な向上につながります。

于 2015-11-30T01:20:42.487 に答える