On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: > >> > What about calling it something even simpler, such as "max_parallelism"? >> > This avoids such cargo cult, and there's no implication that it's >> > per-query. >> >> So what would we call the "parallel_degree" member of the Path data >> structure, and the "parallel_degree" reloption? I don't think >> renaming either of those to "parallelism" is going to be an >> improvement. > > I think we should define the UI first, *then* decide what to call the > internal variable names. In most cases we're able to call the variables > the same as the user-visible names, but not always and there's no rule > that it must be so. Having source code variable names determine what > the user visible name is seems to me like putting the cart before the > horse. > > I think the word "degree" is largely seen as a bad idea: it would become > a somewhat better idea only if we change how it works so that it matches > what other DBMSs do, but you oppose that. Hence my proposal to get rid > of that word in the UI. (My first thought yesterday was to look for > synonyms for the "degree" word, so I got as far as "amount of > parallelism" when I realized that such accompanying words add no value > and so we might as well not have any word there.)
Well I agree with that up to a point, but I think ALTER TABLE foo SET (parallelism = 4) is not a model of clarity. "parallelism" or "parallel" is not obviously an integer quality. I guess we could s/parallel_degree/parallel_workers/g. I find that terminology less elegant than "parallel degree", but I can live with it. -- 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
