L'aumento di work_mem sembrava rendere l'ordinamento circa 8 volte più veloce:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Ma poiché l'ordinamento ha occupato solo una piccola parte del tempo di esecuzione complessivo, renderlo anche 1000 volte più veloce non può rendere le cose molto migliori nel complesso. È la scansione sequenziale che sta prendendo tempo.
La maggior parte del tempo nella scansione di sequenza è probabilmente dedicato a IO. Puoi vedere eseguendo EXPLAIN (ANALYZE, BUFFERS) dopo aver attivato track_io_timing.
Inoltre, la parallelizzazione di una scansione sequenziale spesso non è molto utile, poiché il sistema IO è solitamente in grado di fornire la sua piena capacità a un singolo lettore, grazie alla magia del readahead. E a volte i lettori paralleli possono persino calpestarsi l'un l'altro, peggiorando l'intera performance. Puoi disabilitare la parallelizzazione con set max_parallel_workers_per_gather TO 0; Ciò potrebbe rendere le cose più veloci e, in caso contrario, renderà il piano EXPLAIN più facile da capire.
Stai recuperando oltre il 3% della tabella:193963 / (193963 + 6041677) . Gli indici potrebbero non essere molto utili quando ne stai recuperando così tanto. Se dovessero esserlo, vorresti un indice combinato, non quelli individuali. Quindi vorresti un indice su (client, event_name, date(datetime)) . Quindi dovresti anche modificare la query per utilizzare date(datetime) anziché to_char(datetime, 'YYYY-MM-DD') . Devi apportare questa modifica perché to_char non è immutabile e quindi non può essere indicizzato.
