On Wed, Mar 8, 2017 at 8:45 PM, Peter Geoghegan <p...@bowt.ie> wrote: >> This part I'm not sure about. I think people care quite a lot about >> pg_restore speed, because they are often down when they're running it. >> And they may have oodles mode CPUs that parallel restore can use >> without help from parallel query. I would be inclined to leave >> pg_restore alone and let the chips fall where they may. > > I thought that we might want to err on the side of preserving the > existing behavior, but arguably that's actually what I failed to do. > That is, since we don't currently have a pg_restore flag that controls > the maintenance_work_mem used by pg_restore, "let the chips fall where > they may" is arguably the standard that I didn't uphold. > > It might still make sense to take a leaf out of the parallel query > book on this question. That is, add an open item along the lines of > "review behavior of pg_restore with parallel CREATE INDEX" that we > plan to deal with close to the release of Postgres 10.0, when feedback > from beta testing is in. There are a number of options, none of which > are difficult to write code for. The hard part is determining what > makes most sense for users on balance.
I like to err on the side of the approach that requires fewer changes. That is, if the question is "does pg_restore need to treat this issue specially?" and the answer is unclear, I like to assume it probably doesn't until some contrary evidence emerges. I mean, sometimes it is clear that you are going to need special handling someplace, and then you have to do it. But I don't see that this is one of those cases, necessarily. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers