Date: Fri, 17 Mar 2023 10:07:20 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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>
Subject: Re: pg_dump versus hash partitioning
Message-ID: <20230317020720.3752vjir2qhjtrur@jrouhaud>
References: <1533086.1675349554@sss.pgh.pa.us>
 <1912821.1676402493@sss.pgh.pa.us>
 <20230311030154.pg63uspio35h4a6t@jrouhaud>
 <1078804.1678504214@sss.pgh.pa.us>
 <20230311033232.g6jgkuzxdawepsbe@jrouhaud>
 <1602203.1678650412@sss.pgh.pa.us>
 <20230313083314.pivmgfu36fi4eu2n@jrouhaud>
 <2441413.1678750752@sss.pgh.pa.us>
 <20230316090352.v2m2d473fcv5tli6@jrouhaud>
 <3756156.1678970636@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3756156.1678970636@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/20230317020720.3752vjir2qhjtrur%40jrouhaud>
Precedence: bulk

On Thu, Mar 16, 2023 at 08:43:56AM -0400, Tom Lane wrote:
> Julien Rouhaud <rjuju123@gmail.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:
>
> https://commitfest.postgresql.org/42/4226/

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.