L'augmentation de work_mem semblait rendre le tri environ 8 fois plus rapide :(172639.670 - 169311.063) / (167975.549 - 167570.669) . Mais comme le tri n'a pris qu'une petite fraction du temps d'exécution global, le rendre encore 1000 fois plus rapide ne peut pas améliorer les choses dans l'ensemble. C'est le scan seq qui prend du temps.
Une grande partie du temps de l'analyse seq est probablement consacrée aux E/S. Vous pouvez voir en exécutant EXPLAIN (ANALYZE, BUFFERS) après avoir activé track_io_timing.
De plus, la parallélisation d'un scan seq n'est souvent pas très utile, car le système IO est généralement capable de fournir sa pleine capacité à un seul lecteur, en raison de la magie de la lecture anticipée. Et parfois, les lecteurs parallèles peuvent même se marcher sur les pieds, ce qui aggrave la performance. Vous pouvez désactiver la parallélisation avec set max_parallel_workers_per_gather TO 0; Cela pourrait accélérer les choses, et si ce n'est pas le cas, cela rendra au moins le plan EXPLAIN plus facile à comprendre.
Vous récupérez plus de 3 % du tableau :193963 / (193963 + 6041677) . Les index peuvent ne pas être très utiles lorsque vous en récupérez autant. S'ils doivent l'être, vous voudriez un index combiné, et non des index individuels. Donc, vous voudriez un index sur (client, event_name, date(datetime)) . Ensuite, vous devrez également modifier la requête pour utiliser date(datetime) plutôt que to_char(datetime, 'YYYY-MM-DD') . Vous devez apporter cette modification car to_char n'est pas immuable et ne peut donc pas être indexé.
