pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Dimitrios Apostolou <jimis@gmx.net>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward
Date: Sat, 14 Jun 2025 18:17:41 +0200 (CEST)
Message-ID: <72d2c81b-a0fe-3d99-9dd4-0d771e6e673e@gmx.net> (raw )
In-Reply-To: <f99e9774-da49-60f0-20e0-b97d9f12a04e@gmx.net >
References: <2edb7a57-b225-3b23-a680-62ba90658fec@gmx.net >
<a7344d8f-927c-1f97-6cc0-ac630deb98c4@gmx.net >
<c0e531f9-accc-3a93-e9e6-2cec1471f9e9@gmx.net >
<1282067.1744651649@sss.pgh.pa.us >
<c6bb93c1-4042-743c-096c-27c5e7c73347@gmx.net >
<f7a23708-c336-c189-f155-4b3197bf6ea0@gmx.net >
<aEioDuePEBRnfJYk@nathan >
<5ed51587-5a24-4d79-e36e-927620d0e3a2@gmx.net >
<aEygf8AchBk04gOA@nathan >
<f99e9774-da49-60f0-20e0-b97d9f12a04e@gmx.net >
On Sat, 14 Jun 2025, Dimitrios Apostolou wrote:
> On Fri, 13 Jun 2025, Nathan Bossart wrote:
>
>> On Fri, Jun 13, 2025 at 01:00:26AM +0200, Dimitrios Apostolou wrote:
>>> 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?
>>
>> I may have missed it, but could you share what the strace looks like with
>> the patch applied?
>
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 12288) = 12288
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 12288) = 12288
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 12288) = 12288
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 12288) = 12288
> read(4, "..."..., 4096) = 4096
> read(4, "..."..., 8192) = 8192
> read(4, "..."..., 4096) = 4096
This was from pg_restoring a zstd-compressed custom format dump.
Out of curiosity I've tried the same with an uncompressed dump
(--compress=none). Surprisingly it seems the blocksize is even smaller.
With my patched pg_restore I only get 4K reads and nothing else on
the strace output.
read(4, "..."..., 4096) = 4096
read(4, "..."..., 4096) = 4096
read(4, "..."..., 4096) = 4096
read(4, "..."..., 4096) = 4096
read(4, "..."..., 4096) = 4096
read(4, "..."..., 4096) = 4096
The unpatched pg_restore gives me the weirdest output ever:
read(4, "..."..., 4096) = 4096
lseek(4, 98527916032, SEEK_SET) = 98527916032
lseek(4, 98527916032, SEEK_SET) = 98527916032
lseek(4, 98527916032, SEEK_SET) = 98527916032
lseek(4, 98527916032, SEEK_SET) = 98527916032
lseek(4, 98527916032, SEEK_SET) = 98527916032
lseek(4, 98527916032, SEEK_SET) = 98527916032
[ ... repeats about 80 times ...]
read(4, "..."..., 4096) = 4096
lseek(4, 98527920128, SEEK_SET) = 98527920128
lseek(4, 98527920128, SEEK_SET) = 98527920128
lseek(4, 98527920128, SEEK_SET) = 98527920128
lseek(4, 98527920128, SEEK_SET) = 98527920128
[ ... repeats ... ]
Seeing this, I think we should really consider raising the pg_dump block
size like Tom suggested on a previous thread.
Dimitris
view thread (47+ messages) latest in thread
Message-ID: <72d2c81b-a0fe-3d99-9dd4-0d771e6e673e@gmx.net>
Permalink: ../72d2c81b-a0fe-3d99-9dd4-0d771e6e673e@gmx.net/
Also on: postgresql.org/message-id/72d2c81b-a0fe-3d99-9dd4-0d771e6e673e@gmx.net
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jimis@gmx.net, nathandbossart@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward
In-Reply-To: <72d2c81b-a0fe-3d99-9dd4-0d771e6e673e@gmx.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox