Message-ID: <7b130ad352a908b34281a2205dd58660a9b90b1d.camel@cybertec.at>
Subject: Re: pg_dump versus hash partitioning
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Andrew <pgsqlhackers@andrewrepp.com>
Date: Thu, 02 Feb 2023 10:51:14 +0100
In-Reply-To: <1426306.1675291744@sss.pgh.pa.us>
References: <1376149.1675268279@sss.pgh.pa.us>
	 <CA+TgmoaZ8kDKiQMtDq82Qqqgc5JAfF_UEvc2qa46QwVVLvtMDw@mail.gmail.com>
	 <1412538.1675283692@sss.pgh.pa.us>
	 <CA+TgmoYoSoX8bN_yzabmRDQBNxEaWmjBKPnkZPMUDpPTBy=d4A@mail.gmail.com>
	 <1422349.1675289317@sss.pgh.pa.us>
	 <CA+TgmoYfWKz9wKVNRo8QetFfFKZbk8wrbxWN5EBpw_qYWT5WLw@mail.gmail.com>
	 <1426306.1675291744@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/7b130ad352a908b34281a2205dd58660a9b90b1d.camel%40cybertec.at>
Precedence: bulk

On Wed, 2023-02-01 at 17:49 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Feb 1, 2023 at 5:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > I can agree with that argument for range or list partitioning, where
> > > the partitions have some semantic meaning to the user.=C2=A0 I don't =
buy it
> > > for hash partitioning.=C2=A0 It was an implementation artifact to beg=
in
> > > with that a given row ended up in partition 3 not partition 11, so wh=
y
> > > would users care which partition it ends up in after a dump/reload?
> > > If they think there is a difference between the partitions, they need
> > > education.
>=20
> > I see your point. I think it's somewhat valid. However, I also think
> > it muddies the definition of what pg_dump is allowed to do in a way
> > that I do not like. I think there's a difference between the CTID or
> > XMAX of a tuple changing and it ending up in a totally different
> > partition. It feels like it makes the definition of correctness
> > subjective: we do think that people care about range and list
> > partitions as individual entities, so we'll put the rows back where
> > they were and complain if we can't, but we don't think they think
> > about hash partitions that way, so we will err on the side of making
> > the dump restoration succeed. That's a level of guessing what the user
> > meant that I think is uncomfortable.
>=20
> I see your point too, and to me it's evidence for the position that
> we should never have done hash partitioning in the first place.

You suggested earlier to deprecate hash partitioning.  That's a bit
much, but I'd say that most use cases of hash partitioning that I can
imagine would involve integers.  We could warn against using hash
partitioning for data types other than numbers and date/time in the
documentation.

I also understand the bad feeling of changing partitions during a
dump/restore, but I cannot think of a better way out.

> What do you think of "--load-via-partition-root=3Don/off/auto", where
> auto means "not with hash partitions" or the like?

That's perhaps the best way.  So users who know that their hash
partitions won't change and want the small speed benefit can have it.

Yours,
Laurenz Albe