On 30/07/2018 13:51, Jeff Janes wrote: > Any thoughts on how to proceed here? It seems there is more work to do > to cover all the issues with dumping and restoring tables with many > columns. Since the original report was in the context of pg_upgrade, we > should surely address at least the pg_restore slowness. > > I'll working on solving the problem using a hash table at the lowest > level (making column names unique), for a future commit fest. That > should drop it from N^3 to N^2, which since N can't go above 1600 should > be good enough. > > So we can set this to rejected, as that will be an entirely different > approach. > > Your caching patch might be worthwhile on its own, though.
I'm going to set this thread as returned with feedback until we have a more complete solution. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
