Re: pg_dump versus hash partitioning
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@lists.postgresql.org,
Andrew <pgsqlhackers@andrewrepp.com>
Date: 2023-02-01T22:33:16Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > 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. I think it's categorically better than a failed restore. I wouldn't be proposing this if there were no such problem; but there is, and I don't buy your apparent position that we should leave affected users to cope as best they can. Yes, it's clearly only a minority of users that are affected, else we'd have heard complaints before. But it could be absolutely catastrophic for an affected user, if they're trying to restore their only backup. I'd rather impose an across-the-board cost on all users of hash partitioning than risk such outcomes for a few. Also, you've really offered no evidence for your apparent position that --load-via-partition-root has unacceptable overhead. We've done enough work on partition routing over the last few years that whatever measurements might've originally justified that idea don't necessarily apply anymore. Admittedly, I've not measured it either. But we don't tell people to avoid partitioning because INSERT is unduly expensive. Partition routing is just the cost of doing business in that space. regards, tom lane
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