このクエリはディスクI/Oを生成しませんでした–すべてのブロックが共有バッファから読み取られます。ただし、クエリは73424ブロック（約574 MB）を読み取るため、テーブルがキャッシュされていない場合、かなりのI/O負荷が発生します。
しかし、改善できることが2つあります。
-
不可逆ブロック一致があります ヒープスキャンで。つまり、
work_memはテーブル行ごとのビットを含むビットマップを含むのに十分な大きさではなく、26592ビットは代わりにテーブルブロックをマップします。すべての行を再チェックする必要があり、86733行は破棄されます。そのほとんどは、不可逆ブロックの一致による誤検知です。work_memを増やすと 、テーブル行ごとにビットを含むビットマップがメモリに収まり、この数が減少して、ヒープスキャン中の作業が軽減されます。 -
190108行は、ビットマップヒープスキャンの追加のフィルター条件と一致しないため、破棄されます。これはおそらくほとんどの時間が費やされる場所です。その量を減らすことができれば、あなたは勝ちます。
このクエリの理想的なインデックスは次のとおりです。
CREATE INDEX ON map_listing(transaction_type, la); CREATE INDEX ON map_listing(transaction_type, lo);transaction_typeの場合 あまり選択的ではありません（つまり、ほとんどの行の値はSaleです ）、その列は省略できます。
編集：
vmstatの調査 およびiostat は、CPUとI/Oサブシステムの両方が大規模な過負荷に苦しんでいることを示しています。すべてのCPUリソースはI/O待機とVMスチール時間に費やされています。より優れたI/Oシステムと、より多くの空きCPUリソースを備えたホストシステムが必要です。 RAM migjtを増やすと、I / Oの問題が軽減されますが、ディスクの読み取りのみが対象となります。