MIME-Version: 1.0
References: 
 <CAMT0RQT_0qVxcTT6ycM20QUN-pEQ6iMLbz6gLWgLpeF0NmNOUA@mail.gmail.com>
In-Reply-To: 
 <CAMT0RQT_0qVxcTT6ycM20QUN-pEQ6iMLbz6gLWgLpeF0NmNOUA@mail.gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
Date: Mon, 17 Nov 2025 09:45:17 +0530
Message-ID: 
 <CAFiTN-tV4jWKN75E5YLB-jSqb8j0E1PctiDjztv=ccfbe3YPmg@mail.gmail.com>
Subject: Re: Patch: dumping tables data in multiple chunks in pg_dump
To: Hannu Krosing <hannuk@google.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Nathan Bossart <nathandbossart@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAFiTN-tV4jWKN75E5YLB-jSqb8j0E1PctiDjztv%3Dccfbe3YPmg%40mail.gmail.com>
Precedence: bulk

On Tue, Nov 11, 2025 at 9:00=E2=80=AFPM Hannu Krosing <hannuk@google.com> w=
rote:
>
> Attached is a patch that adds the ability to dump table data in multiple =
chunks.
>
> Looking for feedback at this point:
>  1) what have I missed
>  2) should I implement something to avoid single-page chunks
>
> The flag --huge-table-chunk-pages which tells the directory format
> dump to dump tables where the main fork has more pages than this in
> multiple chunks of given number of pages,
>
> The main use case is speeding up parallel dumps in case of one or a
> small number of HUGE tables so parts of these can be dumped in
> parallel.
>

+1 for the idea, I haven't done the detailed review but I was just
going through the patch, I noticed that we use pg_class->relpages to
identify whether to chunk the table or not, which should be fine but
don't you think if we use direct size calculation function like
pg_relation_size() we might get better idea and not dependent upon
whether the stats are updated or not?  This will make chunking
behavior more deterministic.

--=20
Regards,
Dilip Kumar
Google