Re: pg_dump is broken for partition tablespaces

On Tue, 23 Apr 2019 at 13:49, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> On 2019/04/23 7:51, Alvaro Herrera wrote:
> > To me, it sounds
> > unintuitive to accept partitions that don't exactly match the order of
> > the parent table; but it's been supported all along.
>
> You might know it already, but even though column sets of two tables may
> appear identical, their TupleDescs still may not match due to dropped
> columns being different in the two tables.

I think that's the most likely reason that the TupleDescs would differ
at all. For RANGE partitions on time series data, it's quite likely
that new partitions are periodically created to store new data. If
the partitioned table those belong to evolved over time, gaining new
columns and dropping columns that are no longer needed then some
translation work will end up being required. From my work on
42f70cd9c, I know tuple conversion is not free, so it's pretty good
that pg_dump will remove the need for maps in this case even with the
proposed change.

I imagine users randomly specifying columns for partitions in various
random orders is a less likely scenario, although, it's entirely
possible.

Tom's point about being able to pg_dump a single partition and restore
it somewhere without the parent (apart from an error in ATTACH
PARTITION) seems like it could be useful too, so I'd say that the
pg_dump change is a good one regardless.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services