Att öka work_mem verkade göra sorteringen ungefär 8 gånger snabbare:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Men eftersom sorten bara tog upp en liten bråkdel av den totala exekveringstiden, kan det inte göra saken mycket bättre totalt sett att göra den ännu 1000 gånger snabbare. Det är seq-skanningen som tar upp tiden.
Mycket av tiden i seq-skanningen spenderas förmodligen på IO. Du kan se genom att köra EXPLAIN (ANALYZE, BUFFERS) efter att ha aktiverat track_io_timing.
Dessutom är det ofta inte särskilt användbart att parallellisera en seq-skanning, eftersom IO-systemet vanligtvis kan leverera sin fulla kapacitet till en enda läsare, på grund av magin med readahead. Och ibland kan parallellläsare till och med trampa varandra på tårna, vilket gör hela prestationen sämre. Du kan inaktivera parallellisering med set max_parallel_workers_per_gather TO 0; Detta kan göra saker snabbare, och om det inte gör det kommer det åtminstone att göra EXPLAIN-planen lättare att förstå.
Du hämtar över 3 % av tabellen:193963 / (193963 + 6041677) . Index kanske inte är till stor hjälp när du hämtar så mycket av det. Om de ska vara det, skulle du vilja ha ett kombinerat index, inte individuella. Så du vill ha ett index på (client, event_name, date(datetime)) . Då skulle du också behöva ändra frågan för att använda date(datetime) istället för to_char(datetime, 'YYYY-MM-DD') . Du måste göra denna ändring eftersom to_char inte är oföränderlig och därför inte kan indexeras.