Re: Patch: dumping tables data in multiple chunks in pg_dump

From: Hannu Krosing <hannuk(at)google(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Subject: Re: Patch: dumping tables data in multiple chunks in pg_dump
Date: 2026-01-28 21:27:30
Message-ID: CAMT0RQSXhbLPe3Tru-CU+tB4yrzYWx4P6g9R6gya13ckhqVMyA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi David

About documentation :

On Fri, Jan 23, 2026 at 3:15 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> Aside from that, nothing in the documentation mentions that this is
> for "heap" tables only.

The <note> part did mention it and even gave an example

<varlistentry>
<term><option>--max-table-segment-pages=<replaceable
class="parameter">npages</replaceable></option></term>
<listitem>
<para>
Dump data in segments based on number of pages in the main relation.
If the number of data pages in the relation is more than
<replaceable class="parameter">npages</replaceable>
the data is split into segments based on that number of pages.
Individual segments can be dumped in parallel.
</para>

<note>
<para>
The option <option>--max-table-segment-pages</option> is
applied to only pages
in the main heap and if the table has a large TOASTed part
this has to be
taken into account when deciding on the number of pages to use.
In the extreme case a single 8kB heap page can have ~200
toast pointers each
corresponding to 1GB of data. If this data is also
non-compressible then a
single-page segment can dump as 200GB file.
</para>
</note>

Would it be a good idea to add a 2nd paragraph like this to make it
even more clear ?

<para>
It is also possible that segments end up with very different
sizes even when
no TOAST is involved, as there is no guarantees that pages
are not unevenly
bloated in a real production database up to a point where
some pagese may
have no live tuples in them.
</para>

---
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2026-01-28 21:33:48 Re: Patch: dumping tables data in multiple chunks in pg_dump
Previous Message Peter Smith 2026-01-28 20:59:45 Re: Proposal: Conflict log history table for Logical Replication