L'analyse séquentielle Postgresql ralentit les performances sur 500 millions de lignes

Il n'y a que peu de choses qui vous aideront avec cette requête :

• L'analyse proprement dite ne semble pas être le problème (elle a pris 42 secondes), mais si la table pouvait être conservée dans la RAM, cela pourrait être plus rapide.

• Votre principal problème est le tri, que PostgreSQL parallélise déjà.

  Il y a quelques choses que vous pourriez ajuster :

  • Augmenter work_mem autant que possible, ce qui rendra le tri plus rapide.

  • Augmenter max_worker_processes (cela nécessitera un redémarrage), max_parallel_workers et max_parallel_workers_per_gather afin que davantage de cœurs puissent être utilisés pour la requête.

    PostgreSQL a une logique interne pour calculer le nombre maximum de workers parallèles qu'il est prêt à utiliser pour une table :il considérera autant de workers parallèles que

    log₃ (taille de la table / min_parallel_table_scan_size )

    Vous pouvez le forcer à utiliser plus de processus que cela avec :

    ALTER TABLE ohlcv SET (parallel_workers = 20);
    

    Mais max_parallel_workers est toujours la limite supérieure.

S'il n'y a pas de suppressions et de mises à jour sur la table et que les données sont insérées dans l'ordre de tri, vous pouvez vous en sortir en omettant simplement le ORDER BY clause, à condition que vous définissiez synchronize_seqscans = off .