On Tue, Apr 26, 2016 at 11:22 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Mon, Apr 25, 2016 at 2:58 PM, Alvaro Herrera
>> <alvherre@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
