On Wed, Mar 8, 2017 at 8:45 PM, Peter Geoghegan <pg@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
