Forøgelse af work_mem syntes at gøre sorteringen omkring 8 gange hurtigere:(172639.670 - 169311.063) / (167975.549 - 167570.669) . Men da sorteringen kun optog en lille brøkdel af den samlede udførelsestid, kan det ikke gøre tingene meget bedre generelt at gøre den endnu 1000 gange hurtigere. Det er seq-scanningen, der tager tid.
Meget af tiden i seq-scanningen bliver sandsynligvis brugt på IO. Du kan se ved at køre EXPLAIN (ANALYZE, BUFFERS) efter at have slået track_io_timing til.
Også parallelisering af en seq-scanning er ofte ikke særlig nyttig, da IO-systemet normalt er i stand til at levere sin fulde kapacitet til en enkelt læser på grund af magien ved readahead. Og nogle gange kan parallellæsere endda træde hinanden over tæerne, hvilket gør hele præstationen værre. Du kan deaktivere parallelisering med set max_parallel_workers_per_gather TO 0; Dette kan gøre tingene hurtigere, og hvis det ikke gør det, vil det i det mindste gøre EXPLAIN-planen lettere at forstå.
Du henter over 3 % af tabellen:193963 / (193963 + 6041677) . Indekser er måske ikke særlig nyttige, når du henter så meget af det. Hvis de skal være det, vil du gerne have et kombineret indeks, ikke individuelle. Så du vil have et indeks på (client, event_name, date(datetime)) . Så skal du også ændre forespørgslen til at bruge date(datetime) i stedet for to_char(datetime, 'YYYY-MM-DD') . Du skal foretage denne ændring, fordi to_char ikke er uforanderlig og derfor ikke kan indekseres.