Re: pg_dump versus hash partitioning
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org, Andrew <pgsqlhackers@andrewrepp.com>
Date: 2023-02-01T22:12:41Z
Lists: pgsql-hackers
On Wed, Feb 1, 2023 at 4:44 PM Peter Geoghegan <pg@bowt.ie> wrote: > This is a misrepresentation of Tom's words. It isn't actually > self-evident what "we end up with all of the same objects, each > defined in the same way, and that all of the tables end up with all > the same contents that they had before" actually means here, in > general. Tom's main concern seems to be just that -- the ambiguity > itself. As far as I can see, Tom didn't admit that there was any ambiguity. He just said that I was advocating for wrong behavior for the sake of performance. I don't think that is what I was doing. I also don't really think Tom thinks that that is what I was doing. But it is what he said I was doing. I do agree with you that the ambiguity is the root of the issue. I mean, if we can't put the rows back into the same partitions where they were before, does the user care about that, or do they only care that the rows end up in some partition of the toplevel partitioned table? I think that there's no single definition of correctness that is the only defensible one here, and we can't know which one the user wants a priori. I also think that they can care which one they're getting, and thus I think that changing the default in a minor release is a bad plan. Tom, as I understand it, is arguing that the --load-via-partition-root behavior has negligible downsides and is almost categorically better than the current default behavior, and thus making that the new default in some or all situations in a minor release is totally fine. -- Robert Haas EDB: http://www.enterprisedb.com
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