Re: pg_dump versus hash partitioning
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
David Rowley <dgrowleyml@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers@lists.postgresql.org,
Andrew <pgsqlhackers@andrewrepp.com>
Date: 2023-03-12T20:02:43Z
Lists: pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes: > On Sun, Mar 12, 2023 at 03:46:52PM -0400, Tom Lane wrote: >> What I propose we do about that is further tweak things so that >> load-via-partition-root forces dumping via COPY. AFAIK the only >> compelling use-case for dump-as-INSERTs is in transferring data >> to a non-Postgres database, which is a context in which dumping >> partitioned tables as such is pretty hopeless anyway. (I wonder if >> we should have some way to dump all the contents of a partitioned >> table as if it were unpartitioned, to support such migration.) > I think that what this other thread is about. > https://commitfest.postgresql.org/42/4130/ > pg_dump all child tables with the root table As far as I understood (didn't actually read the latest patch) that one is just about easily selecting all the partitions of a partitioned table when doing a selective dump. It's not helping you produce a non-Postgres-specific dump. Although I guess by combining load-via-partition-root, data-only mode, and dump-as-inserts you could produce a clean collection of non-partition-dependent INSERT commands ... so maybe we'd better not force dump-as-inserts off. I'm starting to like the te->defn hack more. regards, tom lane
Commits
-
Simplify and speed up pg_dump's creation of parent-table links.
- 064709f803c0 16.0 landed
-
Fix pg_dump for hash partitioning on enum columns.
- bc8cd50fefd3 16.0 landed
- 8f83ce8c5244 12.15 landed
- 7e7c5b683985 13.11 landed
- 5fc1ac151d85 14.8 landed
- 2b216da1e55d 15.3 landed
- 012ffb365a05 11.20 landed