| From: | Michael Banck <mbanck(at)gmx(dot)net> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Hannu Krosing <hannuk(at)google(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-03-28 11:26:07 |
| Message-ID: | 20260328112607.GA3202@p46.dedyn.io;lightning.p46.dedyn.io |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Jan 13, 2026 at 03:27:25PM +1300, David Rowley wrote:
> Perhaps --max-table-segment-pages is a better name than
> --huge-table-chunk-pages as it's quite subjective what the minimum
> number of pages required to make a table "huge".
I'm not sure that's better - without looking at the documentation,
people might confuse segment here with the 1GB split of tables into
segments. As pg_dump is a very common and basic user tool, I don't think
implementation details like pages/page sizes and blocks should be part
of its UX.
Can't we just make it a storage size, like '10GB' and then rename it to
--table-parallel-threshold or something? I agree it's bikeshedding, but
I personally don't like either --max-table-segment-pages or
--huge-table-chunk-pages.
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-03-28 13:02:48 | Re: SQL Property Graph Queries (SQL/PGQ) |
| Previous Message | Daniil Davydov | 2026-03-28 11:10:44 | Re: POC: Parallel processing of indexes in autovacuum |