Het verhogen van de work_mem leek de sortering ongeveer 8 keer sneller te maken:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Maar aangezien het soort maar een klein deel van de totale uitvoeringstijd in beslag nam, kan het zelfs 1000 keer sneller maken de zaken in het algemeen niet veel beter maken. Het is de seq-scan die de tijd in beslag neemt.
Een groot deel van de tijd in de seq-scan wordt waarschijnlijk besteed aan IO. U kunt het zien door EXPLAIN (ANALYZE, BUFFERS) . uit te voeren na het inschakelen van track_io_timing.
Ook is het parallelliseren van een seq-scan vaak niet erg nuttig, omdat het IO-systeem meestal in staat is om zijn volledige capaciteit aan een enkele lezer te leveren, vanwege de magie van readahead. En soms kunnen parallelle lezers elkaar zelfs op de tenen trappen, waardoor de hele voorstelling slechter wordt. U kunt parallellisatie uitschakelen met set max_parallel_workers_per_gather TO 0; Dit kan dingen sneller maken, en als dat niet het geval is, wordt het EXPLAIN-plan in ieder geval gemakkelijker te begrijpen.
U haalt meer dan 3% van de tabel op:193963 / (193963 + 6041677) . Indexen zijn misschien niet erg handig als u er zoveel van ophaalt. Als dat zo is, wilt u een gecombineerde index, geen individuele. U wilt dus een index op (client, event_name, date(datetime)) . Dan zou u ook de zoekopdracht moeten wijzigen om date(datetime) . te gebruiken in plaats van to_char(datetime, 'YYYY-MM-DD') . U moet deze wijziging aanbrengen omdat to_char niet onveranderlijk is en dus niet kan worden geïndexeerd.