Re: pg_dump versus hash partitioning
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers@lists.postgresql.org,
Andrew <pgsqlhackers@andrewrepp.com>
Date: 2023-02-02T01:03:10Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > Digging into the history a bit, I found [2] and particularly [3] that > seem to indicate this option was thought about due to concerns about > hash functions not returning consistent results on different > architectures. I suspect it might have been defaulted to load into the > leaf partitions for performance reasons, however. I mean, why else > would you? > [3] https://www.postgresql.org/message-id/CA%2BTgmoZFn7TJ7QBsFatnuEE%3DGYGdZSNXqr9489n5JBsdy5rFfA%40mail.gmail.com Hah ... so we went over almost exactly this same ground in 2017. The consensus at that point seemed to be that actual problems would be rare enough that we'd not need to impose the overhead of --load-via-partition-root by default. Now, AFAICS that was based on exactly zero hard evidence, as to either the frequency of actual problems or the cost of --load-via-partition-root. Our optimism about the former seems to have been mostly borne out, given the lack of complaints since then; but I still think our pessimism about the latter is on shaky grounds. Anyway, after re-reading the old thread I wonder if my first instinct (force --load-via-partition-root for enum hash cases only) was the best compromise after all. I'm not sure how painful it is to get pg_dump to detect such cases, but it's probably possible. 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