On Sat, Aug 29, 2020 at 12:43 AM Jakub Wartak <jakub.war...@tomtom.com> wrote: > ... %CPU ... COMMAND > ... 97.4 ... postgres: startup recovering 000000010000000000000089
So, what else is pushing this thing off CPU, anyway? For one thing, I guess it might be stalling while reading the WAL itself, because (1) we only read it 8KB at a time, relying on kernel read-ahead, which typically defaults to 128KB I/Os unless you cranked it up, but for example we know that's not enough to saturate a sequential scan on NVME system, so maybe it hurts here too (2) we keep having to switch segment files every 16MB. Increasing WAL segment size and kernel readahead size presumably help with that, if indeed it is a problem, but we could also experiment with a big POSIX_FADV_WILLNEED hint for a future segment every time we cross a boundary, and also maybe increase the size of our reads.
