work_memを増やすと、並べ替えが約8倍速くなるようです：(172639.670 - 169311.063) / (167975.549 - 167570.669) 。ただし、並べ替えにかかる時間は全体の実行時間のごく一部であるため、1000倍高速化しても、全体としてはそれほど改善されません。時間がかかっているのはseqスキャンです。
seqスキャンの時間の多くは、おそらくIOに費やされています。 EXPLAIN (ANALYZE, BUFFERS)を実行すると確認できます track_io_timingをオンにした後。
また、先読みの魔法のために、IOシステムは通常、その全容量を単一のリーダーに提供できるため、seqスキャンの並列化はあまり役に立ちません。また、並列リーダーが互いにつま先を踏むことさえあり、全体のパフォーマンスが低下することがあります。 set max_parallel_workers_per_gather TO 0;を使用して、並列化を無効にできます。 これにより、処理が速くなる可能性があります。そうでない場合は、少なくともEXPLAIN計画が理解しやすくなります。
テーブルの3％以上をフェッチしています：193963 / (193963 + 6041677) 。インデックスを大量に取得している場合、インデックスはあまり役に立たない可能性があります。そうである場合は、個別のインデックスではなく、組み合わせたインデックスが必要になります。したがって、(client, event_name, date(datetime))のインデックスが必要になります 。次に、date(datetime)を使用するようにクエリを変更する必要もあります。 to_char(datetime, 'YYYY-MM-DD')ではなく 。 to_charは不変ではないため、インデックスを作成できないため、この変更を行う必要があります。