Das Erhöhen von work_mem schien die Sortierung etwa 8-mal schneller zu machen:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Aber da das Sortieren nur einen kleinen Bruchteil der gesamten Ausführungszeit in Anspruch nahm, kann eine noch 1000-mal schnellere Ausführung die Dinge insgesamt nicht viel besser machen. Es ist der Seq-Scan, der die Zeit in Anspruch nimmt.
Ein Großteil der Zeit im Seq-Scan wird wahrscheinlich für IO aufgewendet. Sie können dies sehen, indem Sie EXPLAIN (ANALYZE, BUFFERS) ausführen nach dem Einschalten von track_io_timing.
Auch die Parallelisierung eines Seq-Scans ist oft nicht sehr hilfreich, da das IO-System aufgrund der Magie des Vorauslesens normalerweise in der Lage ist, seine volle Kapazität an einen einzelnen Leser zu liefern. Und manchmal können sich Parallelleser sogar gegenseitig auf die Zehen treten, was die gesamte Leistung verschlechtert. Sie können die Parallelisierung mit set max_parallel_workers_per_gather TO 0; deaktivieren Dies könnte die Dinge beschleunigen, und wenn nicht, wird es zumindest den EXPLAIN-Plan verständlicher machen.
Sie rufen über 3 % der Tabelle ab:193963 / (193963 + 6041677) . Indizes sind möglicherweise nicht sehr hilfreich, wenn Sie so viel davon abrufen. Wenn dies der Fall sein sollte, möchten Sie einen kombinierten Index, keine einzelnen. Sie möchten also einen Index für (client, event_name, date(datetime)) . Dann müssten Sie auch die Abfrage ändern, um date(datetime) zu verwenden statt to_char(datetime, 'YYYY-MM-DD') . Sie müssen diese Änderung vornehmen, da to_char nicht unveränderlich ist und daher nicht indiziert werden kann.
