Zwiększenie work_mem wydaje się przyspieszać sortowanie około 8 razy:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Ale ponieważ sortowanie zajmowało tylko niewielki ułamek całkowitego czasu wykonania, nawet 1000 razy szybsze nie może ogólnie poprawić. To sekwencjonowanie zajmuje dużo czasu.
Większość czasu w skanowaniu sekwencyjnym prawdopodobnie spędza się na IO. Możesz to zobaczyć, uruchamiając EXPLAIN (ANALYZE, BUFFERS) po włączeniu track_io_timing.
Równolegle skanowanie sekwencyjne często nie jest zbyt pomocne, ponieważ system IO jest zwykle w stanie dostarczyć pełną pojemność do jednego czytnika, dzięki magii odczytu z wyprzedzeniem. A czasami czytelnicy równolegli mogą nawet nadepnąć sobie na palce, pogarszając całą wydajność. Możesz wyłączyć równoległość za pomocą set max_parallel_workers_per_gather TO 0; Może to przyspieszyć działanie, a jeśli nie, przynajmniej ułatwi zrozumienie planu EXPLAIN.
Pobierasz ponad 3% tabeli:193963 / (193963 + 6041677) . Indeksy mogą nie być zbyt pomocne, gdy pobierasz ich tak dużo. Jeśli mają być, chciałbyś mieć indeks łączony, a nie indywidualny. Więc chciałbyś mieć indeks na (client, event_name, date(datetime)) . Następnie musisz również zmienić zapytanie, aby używało date(datetime) zamiast to_char(datetime, 'YYYY-MM-DD') . Musisz wprowadzić tę zmianę, ponieważ to_char nie jest niezmienne, a więc nie może być indeksowane.
