大きなテーブルで日付ベースのクエリのパフォーマンスを向上させるにはどうすればよいですか？

マテリアライズドビュー あなたが概説したもののために行く方法です。過去数か月の読み取り専用データのクエリは、更新しなくても機能します。それをカバーする必要がある場合は、今月を特別なケースにすることもできます。

基になるクエリは引き続きインデックスの恩恵を受けることができ、2つの方向性があります。

まず、部分インデックスあなたが今あなたのシナリオで多くを買わないように、それの価値はありません。さらに多くの月のデータを収集し、ほとんどの場合月ごとにクエリを実行する（および月ごとに行を追加/削除する）場合テーブルパーティショニングアイデアかもしれませんが、インデックスも自動的にパーティション化されます。ただし、これにはPostgres11または今後のPostgres12を検討したいと思います。）

行が広い場合、 インデックスのみのスキャンを許可するインデックスを作成します 。いいね：

CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal, views, gender);

関連：

b-treeインデックスがそのフィールドに構築されている場合、PostgreSQLはORDER BYをどのように実行しますか？

またはINCLUDE Postgres 11以降の追加の列：

CREATE INDEX reportimpression_covering_idx ON reportimpression(datelocal) INCLUDE (views, gender);

その他 、行がdatelocalで物理的に並べ替えられている場合、 BRINインデックスを検討してください 。これは非常に小さく、おそらくあなたのケースのBツリーインデックスとほぼ同じ速さです。（ただし、非常に小さいため、キャッシュされたままになり、他のデータをそれほどプッシュしません。）

CREATE INDEX reportimpression_brin_idx ON reportimpression USING BRIN (datelocal);

CLUSTERに興味があるかもしれません。または pg_repack テーブルの行を物理的に並べ替えます。 pg_repack テーブルの排他ロックなしで、またbtreeインデックスなしでもそれを行うことができます（CLUSTERで必要））。ただし、これはPostgresの標準ディストリビューションに付属していない追加のモジュールです。