Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward - Mailing list pgsql-hackers

From Dimitrios Apostolou
Subject Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward
Date
Msg-id 5ed51587-5a24-4d79-e36e-927620d0e3a2@gmx.net
Whole thread Raw
In response to [PATCH v1] parallel pg_restore: avoid disk seeks when jumping short distance forward  (Dimitrios Apostolou <jimis@gmx.net>)
Responses Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward
List pgsql-hackers
On Tue, 10 Jun 2025, Nathan Bossart wrote:

> So, fseeko() starts winning around 4096 bytes.  On macOS, the differences
> aren't quite as dramatic, but 4096 bytes is the break-even point there,
> too.  I imagine there's a buffer around that size somewhere...
>
> This doesn't fully explain the results you are seeing, but it does seem to
> validate the idea.  I'm curious if you see further improvement with even
> lower thresholds (e.g., 8KB, 16KB, 32KB).

By the way, I might have set the threshold to 1MB in my program, but
lowering it won't show a difference in my test case, since the lseek()s I
was noticing before the patch were mostly 8-16KB forward. Not sure what is
the defining factor for that. Maybe the compression algorithm, or how wide
the table is?


Dimitris




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: pg_dump --with-* options
Next
From: Perumal Raj
Date:
Subject: Re: Logical Replication slot disappeared after promote Standby