MIME-Version: 1.0
References: <CAMT0RQT_0qVxcTT6ycM20QUN-pEQ6iMLbz6gLWgLpeF0NmNOUA@mail.gmail.com>
 <CAExHW5t54GPKFbW3KLzintJ6jMMRYwb-t2Fjm4JTxEcZbGDomA@mail.gmail.com>
 <CAMT0RQTHoL8S7OonFWC_aDSC-2oX7BGBBLAQ+OOBhRPcxV2eiw@mail.gmail.com>
 <CAMT0RQQAH1a8kY-mx7B07Uzn3T_zeaU9detqFFtW36_k67Su+A@mail.gmail.com>
 <CAMT0RQQr7KtPAY903+F42csiHc1EPHo70Xji-znkxEhwdoKa6w@mail.gmail.com>
 <CAMT0RQSNHFffbCmDNxQogVBD8H5gTDJNwhUR2btCVE+Lq1sGGw@mail.gmail.com>
 <CAMT0RQTEFGctCfgVx3u2XgVRCAj_QURV2tfdzL0HOQi=u0sV2A@mail.gmail.com>
 <CAApHDvr8ay+31Wd0TptDGp8cAg2-NOnWddx8csnUE3R03EbvZw@mail.gmail.com>
 <CAMT0RQShjXPPdXQS-5uzDC3bXt+QEZR5tO02o1NHdXWNu2quvw@mail.gmail.com>
 <CAN4CZFOTOX1nFkPrmM7fQ9qnrccvjwywXPf4Eo7C+DF-h-x96g@mail.gmail.com>
 <CAMT0RQTbQxjdN5nv6M_HhFWiLqdT84=NYBM1ZYQKaAcf8Ufyaw@mail.gmail.com>
 <CAN4CZFOjG2kUciKeVBpxrHJZNkZuzY_Q5ij_qpDZcAS3Ak2GxA@mail.gmail.com>
 <CAMT0RQStjytRrGTe0X03ErC7anwxNRHAULYBsSmdWZV3fr4-Dg@mail.gmail.com>
 <CAMT0RQROPMSPwfxAUCm1gZs9cUr7FmvwX+eO6Wzq_wWdd6eEAQ@mail.gmail.com>
 <CAMT0RQQ8DX+K7OTw3Lg+Yp2ew8TsZduiqtPszfiBixcpxKbz-A@mail.gmail.com> <CAApHDvo29-vQz=xV6+x5hU--NZ9qGPXsCNBuOAf88pAHjTpvvQ@mail.gmail.com>
In-Reply-To: <CAApHDvo29-vQz=xV6+x5hU--NZ9qGPXsCNBuOAf88pAHjTpvvQ@mail.gmail.com>
From: Hannu Krosing <hannuk@google.com>
Date: Wed, 28 Jan 2026 22:27:30 +0100
Message-ID: <CAMT0RQSXhbLPe3Tru-CU+tB4yrzYWx4P6g9R6gya13ckhqVMyA@mail.gmail.com>
Subject: Re: Patch: dumping tables data in multiple chunks in pg_dump
To: David Rowley <dgrowleyml@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>, 
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, 
	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/CAMT0RQSXhbLPe3Tru-CU%2BtB4yrzYWx4P6g9R6gya13ckhqVMyA%40mail.gmail.com>
Precedence: bulk

Hi David

About documentation :

On Fri, Jan 23, 2026 at 3:15=E2=80=AFAM David Rowley <dgrowleyml@gmail.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=3D<replaceable
class=3D"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=3D"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