Re: pg_dump versus hash partitioning

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew <pgsqlhackers(at)andrewrepp(dot)com>
Subject: Re: pg_dump versus hash partitioning
Date: 2023-03-17 02:07:20
Message-ID: 20230317020720.3752vjir2qhjtrur@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Mar 16, 2023 at 08:43:56AM -0400, Tom Lane wrote:
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> > On Mon, Mar 13, 2023 at 07:39:12PM -0400, Tom Lane wrote:
> >> Yeah, we need to do both. Attached find an updated patch series:
> > I didn't find a CF entry, is it intended?
> Yeah, it's there:

Ah thanks! I was looking for "pg_dump" in the page.

> > I'm not sure if you intend to keep the current 0002 - 0003 separation, but if
> > yes the part about te->defn and possible fallback should be moved to 0003. In
> > 0002 we're only looking at the COPY statement.
> I was intending to smash it all into one commit --- the separation is
> just to ease review.

Ok, no problem then and I agree it's better to squash them.

> > I know you're only inheriting this comment, but isn't it well outdated and not
> > accurate anymore? I'm assuming that "archiving is not on" was an acceptable
> > way to mean "wal_level < archive" at some point, but it's now completely
> > misleading.
> Sure, want to propose wording?

Just mentioning the exact wal_level, something like

* [...]. If wal_level is set to minimal this prevents
* WAL-logging the COPY. This obtains a speedup similar to
* [...]

> > More generally, I also think that forcing --load-via-partition-root for
> > known unsafe partitioning seems like the best compromise. I'm not sure if we
> > should have an option to turn it off though.
> I think the odds of that yielding a usable dump are nil, so I don't
> see why we should bother.

No objection from me.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message 2023-03-17 02:26:19 RE: Allow logical replication to copy tables in binary format
Previous Message Peter Geoghegan 2023-03-17 02:03:12 Re: Add pg_walinspect function with block info columns