| From: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward |
| Date: | 2025-06-11 23:25:00 |
| Message-ID: | 50d0e587-3c6c-fec8-4937-efee4a59a6cf@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 11 Jun 2025, Nathan Bossart wrote:
> On Wed, Jun 11, 2025 at 12:32:58AM +0200, Dimitrios Apostolou wrote:
>> what read-seek pattern do you see on the system call level (as shown by
>> strace)? In pg_restore it was a constant loop of read(4K)-lseek(8-16K).
>
> For fseeko(), sizes less than 4096 produce a repeating pattern of read()
> calls followed by approximately (4096 / size) lseek() calls. For greater
> sizes, it's just a stream of lseek().
This is the opposite of what the link you shared before describes, so
maybe glibc has changed its behaviour to improve performance.
Anyway, the fact that fseek(>4096) produces a stream of lseek()s, means
that most likely no I/O is happening. You need to issue a getc() after
each fseeko(), like pg_restore is doing.
Dimitris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noboru Saito | 2025-06-11 23:49:11 | Re: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths |
| Previous Message | Tatsuo Ishii | 2025-06-11 22:52:35 | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |