| From: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitrios Apostolou <jimis(at)gmx(dot)net> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward |
| Date: | 2025-10-20 22:09:46 |
| Message-ID: | 7B29E5B2-94DC-48ED-A1F3-247BCE5A2329@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-10-20 22:15:13 | Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward |
| Previous Message | John H | 2025-10-20 22:03:55 | Re: Making pg_rewind faster |