では早速、原因を究明するために、実際に問題となっているクエリの詳細を確認していきましょう！

まずはクエリ（query=2018321）がどのぐらいの回数で実行されたかや、
最大/平均実行時間、実行されたクエリ文を見てみます。

～以降、記載されているクエリは管理者ユーザー（例：awsuser）で実行しています ～

SELECT
query,
COUNT(*) AS exec_count,                                                     -- 実行回数
MAX(DATEDIFF(microseconds, starttime, endtime)) AS max_exec_time_microsec,  -- 最大実行時間
AVG(DATEDIFF(microseconds, starttime, endtime)) AS avg_exec_time_microsec,  -- 平均実行時間
querytxt                                                                    -- クエリ文
FROM
stl_query
where
query=2018321                                                               -- 確認した query 値を指定
group BY query,querytxt;

※stl_query はクエリ情報の履歴が確認できるテーブルです。

※今回は含めていませんが、↑のクエリに starttime や endtime を条件に追加して、
　事象発生時間帯だけに絞ってみるのもオススメです！

querytxt 列を見てみると、どうやら test_table というテーブルに対して、
id=1 で絞って参照しようとしているみたいですね～

また、1回（exec_count）だけ実行されていて、6055193 マイクロ秒（約6秒）要していることが判明しました。
（テストテーブルのくせに生意気な！！）

ちなみに余談ですが、このテーブルには、id 列（一意の値）と value 列があって、
以下のようなデータが全部で1000万件入っています。

【格納例】

　　※ここでは詳細な説明は省略しますが、クエリプランとはテーブルのスキャン・結合・集計など、
　　　クエリを実行する手順（ステップ）を示します。詳細は公式ドキュメントをご参照ください。

まずは過去の履歴から追ってみようと思うので、stl_explain という過去（事象発生時）の
クエリプランを参照できるテーブルから確認してみます。
（現在のクエリプランを取得する方法として EXPLAIN があります。次回の記事で試します！）

SELECT plannode || ' ' || info as SqlPlan
FROM stl_explain
WHERE query = 2018321 -- 確認した query の値を指定
ORDER BY nodeid;

実運用で実行されているクエリの場合、クエリプランはもっと複雑で長文になる可能性が十分にありますが、
今回は至ってシンプルです。

ただ、どんなクエリプランだって見るべき所は大体同じ（ハズ）です！

どこのステップで、時間を要していそうか（コストが高そうか）や 多くのレコードにアクセスしていそうか
に着目して確認してみましょう！

　　※もっとクエリプランの見方について知りたい方は「クエリプランステップの確認」をご参照ください。

今回のクエリプランでは、「XN Seq Scan on test_table」とあるので、シーケンシャルスキャン
（＝テーブル全体を順番にスキャンして条件に合致する行を探す方法）を示しています。

つまり、test_table というテーブルの全ての行を順に読み込み、
id=1 のレコードを抽出しようとしているようです。
1000万件も格納されている訳ですし、なんか無駄な読み込みが発生していそうですよね。。

前回、「ソートキー が見つからない or 正しく設定されていない場合に
Very selective query filter（非常に選択的なフィルター）が発生する」と
STL_ALERT_EVENT_LOG が教えてくれましたよね。

ってなわけで、問題となっているクエリの中で参照しているテーブル（test_table）に
ソートキーが存在するかチェックしてみましょう。

SELECT tablename, "column", type, encoding, distkey, sortkey
FROM pg_table_def
WHERE tablename = 'test_table'; -- クエリプランで確認したテーブル名を指定

sortkey=0 となっていることから、id 列には現在ソートキーが存在しないと判断できます。
STL_ALERT_EVENT_LOG（solution 列）の予想的中です！お見事！！