Aumentar o work_mem pareceu tornar a classificação cerca de 8 vezes mais rápida:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Mas como a classificação ocupava apenas uma pequena fração do tempo total de execução, torná-la até 1.000 vezes mais rápida não pode tornar as coisas muito melhores no geral. É a varredura seq que está ocupando o tempo.

Muito do tempo na varredura seq é provavelmente gasto em IO. Você pode ver executando EXPLAIN (ANALYZE, BUFFERS) depois de ativar track_io_timing.

Além disso, paralelizar uma varredura seq geralmente não é muito útil, pois o sistema IO geralmente é capaz de fornecer sua capacidade total a um único leitor, devido à mágica do readahead. E às vezes os leitores paralelos podem até pisar nos pés uns dos outros, piorando todo o desempenho. Você pode desabilitar a paralelização com set max_parallel_workers_per_gather TO 0; Isso pode tornar as coisas mais rápidas e, se não, pelo menos tornará o plano EXPLAIN mais fácil de entender.

Você está buscando mais de 3% da tabela:193963 / (193963 + 6041677) . Os índices podem não ser muito úteis quando você está buscando muito deles. Se forem, você gostaria de um índice combinado, não individual. Então você gostaria de um índice em (client, event_name, date(datetime)) . Então você também precisaria alterar a consulta para usar date(datetime) em vez de to_char(datetime, 'YYYY-MM-DD') . Você precisa fazer essa alteração porque to_char não é imutável e, portanto, não pode ser indexado.