Skanowanie sekwencyjne Postgresql ma niską wydajność na 500 milionach wierszy

Jest tylko kilka rzeczy, które pomogą w tym zapytaniu:

• Samo skanowanie nie wydaje się być problemem (zajęło 42 sekundy), ale gdyby tabelę można było przechowywać w pamięci RAM, mogłoby to być szybsze.

• Twoim głównym problemem jest rodzaj, który PostgreSQL już zrównoleglał.

  Jest kilka rzeczy, które możesz dostroić:

  • Zwiększ work_mem jak najwięcej, co przyspieszy sortowanie.

  • Zwiększ max_worker_processes (będzie to wymagało ponownego uruchomienia), max_parallel_workers i max_parallel_workers_per_gather aby więcej rdzeni mogło być użytych w zapytaniu.

    PostgreSQL ma wewnętrzną logikę obliczania maksymalnej liczby równoległych procesów roboczych, których jest gotowy do użycia dla tabeli:uwzględni tyle równoległych procesów roboczych, ile

    log₃ (rozmiar tabeli / min_parallel_table_scan_size )

    Możesz zmusić go do użycia większej liczby procesów za pomocą:

    ALTER TABLE ohlcv SET (parallel_workers = 20);
    

    Ale max_parallel_workers nadal jest górną granicą.

Jeśli w tabeli nie ma żadnych usunięć ani aktualizacji, a dane są wstawiane w kolejności sortowania, możesz po prostu pominąć ORDER BY klauzula, pod warunkiem, że ustawisz synchronize_seqscans = off .