Rendimiento lento del análisis secuencial de Postgresql en 500 millones de filas

Solo hay algunas cosas que ayudarán con esta consulta:

• El escaneo real no parece ser el problema (tardó 42 segundos), pero si la tabla pudiera mantenerse en la RAM, podría ser más rápido.

• Su principal problema es el tipo, que PostgreSQL ya paraleliza.

  Hay algunas cosas que podrías ajustar:

  • Aumentar work_mem tanto como sea posible, lo que hará que la clasificación sea más rápida.

  • Aumentar max_worker_processes (esto requerirá un reinicio), max_parallel_workers y max_parallel_workers_per_gather para que se puedan usar más núcleos para la consulta.

    PostgreSQL tiene una lógica interna para calcular el número máximo de trabajadores paralelos que está listo para usar en una tabla:considerará tantos trabajadores paralelos como

    registro₃ (tamaño de la tabla / min_parallel_table_scan_size )

    Puede obligarlo a usar más procesos que eso con:

    ALTER TABLE ohlcv SET (parallel_workers = 20);
    

    Pero max_parallel_workers sigue siendo el límite superior.

Si no hay eliminaciones ni actualizaciones en la tabla, y los datos se insertan en orden de clasificación, podría salirse con la suya simplemente omitiendo el ORDER BY cláusula, siempre que establezca synchronize_seqscans = off .