Увеличаването на work_mem изглежда прави сортирането около 8 пъти по-бързо:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Но тъй като сортирането зае само малка част от общото време за изпълнение, правенето му дори 1000 пъти по-бързо не може да направи нещата много по-добри като цяло. Това е последователното сканиране, което отнема времето.
Голяма част от времето в сканирането на seq вероятно се изразходва за IO. Можете да видите, като стартирате EXPLAIN (ANALYZE, BUFFERS) след включване на track_io_timing.
Също така паралелното сканиране на seq често не е много полезно, тъй като IO системата обикновено е в състояние да достави пълния си капацитет на един четец, поради магията на readahead. А понякога паралелните читатели могат дори да се стъпят на пръстите на другия, влошавайки цялото представяне. Можете да деактивирате паралелизирането с set max_parallel_workers_per_gather TO 0; Това може да направи нещата по-бързи, а ако не стане, поне ще направи плана EXPLAIN по-лесен за разбиране.
Извличате над 3% от таблицата:193963 / (193963 + 6041677) . Индексите може да не са много полезни, когато извличате толкова много от тях. Ако трябва да бъдат, бихте искали комбиниран индекс, а не индивидуални. Така че бихте искали индекс на (client, event_name, date(datetime)) . Тогава ще трябва също да промените заявката, за да използвате date(datetime) вместо to_char(datetime, 'YYYY-MM-DD') . Трябва да направите тази промяна, защото to_char не е неизменен и затова не може да бъде индексиран.
