As consultas do Postgres na produção resultam em E/S de leitura de disco anormalmente alta

Esta consulta não produziu nenhuma E/S de disco – todos os blocos são lidos de buffers compartilhados. Mas como a consulta lê 73.424 blocos (cerca de 574 MB), ela produzirá uma carga de E/S substancial quando a tabela não estiver armazenada em cache.

Mas há duas coisas que podem ser melhoradas.

Você tem correspondências de blocos com perdas na varredura de pilha. Isso significa que work_mem não é grande o suficiente para conter um bitmap com um bit por linha de tabela e 26592 bits mapeiam um bloco de tabela. Todas as linhas precisam ser verificadas novamente e 86733 linhas são descartadas, a maioria das quais são falsos positivos das correspondências de blocos com perdas.

Se você aumentar work_mem , um bitmap com um bit por linha da tabela caberá na memória e esse número diminuirá, reduzindo o trabalho durante a varredura de heap.
190108 linhas são descartadas porque não correspondem à condição de filtro adicional na varredura de heap de bitmap. Este é provavelmente o lugar onde a maior parte do tempo é gasto. Se você puder reduzir esse valor, você ganhará.

Os índices ideais para esta consulta seriam:
```
CREATE INDEX ON map_listing(transaction_type, la);
CREATE INDEX ON map_listing(transaction_type, lo);
```
Se transaction_type não é muito seletivo (ou seja, a maioria das linhas tem o valor Sale ), você pode omitir essa coluna.

EDITAR:

Exame de vmstat e iostat mostra que tanto a CPU quanto o subsistema de E/S estão sofrendo de sobrecarga maciça:todos os recursos da CPU são gastos em espera de E/S e tempo de roubo de VM. Você precisa de um sistema de E/S melhor e um sistema host com mais recursos de CPU livres. Aumentar a RAM pode aliviar o problema de E/S, mas apenas para as leituras de disco.