Postgresql sequentiële scan trage prestaties op 500 miljoen rijen

Er zijn maar een paar dingen die helpen bij deze vraag:

• Het daadwerkelijke scannen lijkt niet het probleem te zijn (het duurde 42 seconden), maar als de tabel in het RAM kon worden bewaard, zou het misschien sneller zijn.

• Uw grootste probleem is de soort, die PostgreSQL al parallelliseert.

  Er zijn een paar dingen die je kunt afstemmen:

  • Verhoog work_mem zoveel mogelijk, waardoor het sorteren sneller gaat.

  • Verhoog max_worker_processes (hiervoor is een herstart vereist), max_parallel_workers en max_parallel_workers_per_gather zodat er meer kernen voor de query kunnen worden gebruikt.

    PostgreSQL heeft een interne logica om het maximale aantal parallelle werkers te berekenen dat het klaar is om te gebruiken voor een tabel:het zal evenveel parallelle werkers beschouwen als

    log₃ (tabelgrootte / min_parallel_table_scan_size )

    Je kunt het forceren om meer processen te gebruiken dan dat met:

    ALTER TABLE ohlcv SET (parallel_workers = 20);
    

    Maar max_parallel_workers is nog steeds de bovengrens.

Als er geen verwijderingen en updates in de tabel zijn en de gegevens in sorteervolgorde worden ingevoegd, kunt u wegkomen door gewoon de ORDER BY weg te laten clausule, op voorwaarde dat u synchronize_seqscans = off . instelt .