Las consultas de Postgres en producción dan como resultado una E/S de lectura de disco anormalmente alta

Esta consulta no produjo ninguna E/S de disco:todos los bloques se leen de los búferes compartidos. Pero dado que la consulta lee 73424 bloques (alrededor de 574 MB), producirá una carga de E/S sustancial cuando la tabla no esté en caché.

Pero hay dos cosas que se pueden mejorar.

• Tienes coincidencias de bloque con pérdida en la exploración del montón. Eso significa que work_mem no es lo suficientemente grande para contener un mapa de bits con un bit por fila de tabla, y en su lugar, 26592 bits asignan un bloque de tabla. Se deben volver a verificar todas las filas y se descartan 86733 filas, la mayoría de las cuales son falsos positivos de las coincidencias de bloques con pérdida.

  Si aumenta work_mem , un mapa de bits con un bit por fila de la tabla cabrá en la memoria y este número se reducirá, lo que reducirá el trabajo durante la exploración del montón.

• Se descartan 190108 filas porque no coinciden con la condición de filtro adicional en el análisis del montón de mapa de bits. Aquí es probablemente donde se pasa la mayor parte del tiempo. Si puedes reducir esa cantidad, ganarás.

  Los índices ideales para esta consulta serían:

  CREATE INDEX ON map_listing(transaction_type, la);
  CREATE INDEX ON map_listing(transaction_type, lo);
  

  Si transaction_type no es muy selectivo (es decir, la mayoría de las filas tienen el valor Sale ), puede omitir esa columna.

EDITAR:

Examen de vmstat y iostat muestra que tanto la CPU como el subsistema de E/S sufren una sobrecarga masiva:todos los recursos de la CPU se gastan en espera de E/S y tiempo de robo de VM. Necesita un mejor sistema de E/S y un sistema host con más recursos de CPU libres. El aumento de RAM podría aliviar el problema de E/S, pero solo para las lecturas de disco.