Horton

Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward

Dimitrios Apostolou <jimis@gmx.net>

View thread View on postgr.es
From: Dimitrios Apostolou <jimis@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Dimitrios Apostolou <jimis@gmx.net>
Cc: Chao Li <li.evan.chao@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-20T22:09:46Z
Lists: pgsql-hackers 
Thanks for the extensive testing! Did you see the same syscall pattern in strace output, as I did?

If yes, then the only reason I can think of that excuses the regression with my patch is that the SATA interface was maxed out when reading sequentially, while the very short latency of SSDs guarantees thousands of seek() operations per second.

I was using an HDD, and in older measurements I was using a VM with mounted volume over iSCSI. The first imposes physical limits in the amount of seeks, and the second network round-trip limits.

So you are right, it's probably very platform dependent, and the most important fix was to enlarge the underlying block size, that you have done.


Dimitris

Commits

  1. Avoid short seeks in pg_restore.

  2. Don't rely on zlib's gzgetc() macro.

  3. Add more TAP test coverage for pg_dump.

  4. Split 002_pg_dump.pl into two test files.

  5. Align the data block sizes of pg_dump's various compression modes.

  6. Fix serious performance problems in LZ4Stream_read_internal.

  7. Fix poor buffering logic in pg_dump's lz4 and zstd compression code.

  8. Fix issue with reading zero bytes in Gzip_read.

  9. Restore test coverage of LZ4Stream_gets().