Andres Freund <andres@anarazel.de> writes:
> Which to me rather strongly suggests pg_dump has gotten a *lot* slower with
> this change.
Well, it's doing strictly more work, so somewhat slower is to be
expected. But yeah, more than 2x slower is not nice.
In a quick look at the committed patch, it doesn't seem to have
used any of the speedup strategies we applied to pg_dump a couple
of years ago. One or the other of these should help:
* Issue a single query to fetch stats from every table we're dumping
* Set up a prepared query to avoid re-planning the per-table query
(compare be85727a3)
I'm not sure how workable the first of these would be though.
It's not hard to imagine it blowing out pg_dump's memory usage
for a DB with a lot of tables and high default_statistics_target.
The second one should be relatively downside-free.
regards, tom lane
