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:

Reply via email to