El aumento de work_mem pareció hacer que la ordenación fuera unas 8 veces más rápida:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Pero dado que ordenar solo tomó una pequeña fracción del tiempo de ejecución general, hacerlo incluso 1000 veces más rápido no puede mejorar mucho las cosas en general. Es el análisis secuencial el que está consumiendo el tiempo.
Gran parte del tiempo en el escaneo de secuencias probablemente se dedique a IO. Puede verlo ejecutando EXPLAIN (ANALYZE, BUFFERS) después de activar track_io_timing.
Además, la paralelización de un escaneo secuencial a menudo no es muy útil, ya que el sistema IO generalmente puede entregar su capacidad total a un solo lector, debido a la magia de la lectura anticipada. Y a veces, los lectores paralelos pueden incluso pisar los dedos de los pies, empeorando todo el rendimiento. Puede deshabilitar la paralelización con set max_parallel_workers_per_gather TO 0; Esto podría acelerar las cosas y, si no es así, al menos hará que el plan EXPLAIN sea más fácil de entender.
Está obteniendo más del 3 % de la tabla:193963 / (193963 + 6041677) . Es posible que los índices no sean muy útiles cuando se obtiene tanto. Si van a serlo, querrá un índice combinado, no uno individual. Por lo tanto, desearía un índice en (client, event_name, date(datetime)) . Luego, también deberá cambiar la consulta para usar date(datetime) en lugar de to_char(datetime, 'YYYY-MM-DD') . Debe realizar este cambio porque to_char no es inmutable y, por lo tanto, no se puede indexar.
