On Tue, May 31, 2016 at 1:27 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > This is a very good point. > > I think parallel maintenance commands are going to require different > tuning than different queries, and I'd rather have separate parameters > for those things rather than force the same parameter being changed over > and over depending on what is the session going to execute next.
FWIW, as things stand my parallel CREATE INDEX patch does have a cost model which is pretty close to the one for parallel sequential scan. The cost model cares about max_parallel_degree. However, it also introduces a parallel_degree index storage parameter, which overrides the cost model to make it indicate the number of parallel workers to use (presumably, somebody will change master to make parallel_degree in terms of "participant processes" rather than worker processes soon, at which point I'll follow their lead). The storage parameter sticks around, of course, so a REINDEX will reuse it without asking. (I think CLUSTER should do the same with the index storage parameter.) What's novel about this is that for utility statements, you can override the cost model, and so disregard max_parallel_degree if you so choose. My guess is that DBAs will frequently want to do so. I'm not attached to any of this, but that's what I've come up with to date. Possibly the index storage parameter concept has baggage elsewhere, which comes up when we later go to parallelize index scans. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
