Re: suggest to rename enable_incrementalsort

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: suggest to rename enable_incrementalsort
Дата
Msg-id 2037457.1592836877@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: suggest to rename enable_incrementalsort  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: suggest to rename enable_incrementalsort  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> The reason why I kept the single-word variant is consistency with other
>> GUCs that affect planning, like enable_indexscan, enable_hashjoin and
>> many others.

> Right, so that makes sense, but from a larger point of view, how much
> sense does it actually make?

Maybe I'm just used to the names, but I find that things like
"enable_seqscan" and "enable_nestloop" are pretty readable.
Once they get longer, though, not so much.  So I agree with
renaming enable_incrementalsort.

> So I'm +1 for changing this, and I'd definitely be +1 for renaming the
> others if they weren't released already, and at least +0.5 for it
> anyhow.

Nah.  Those names are way too well entrenched.  Besides which, if
we open them up for reconsideration, there's going to be a lot of
bikeshedding done.  Should "enable_seqscan" become "enable_seq_scan",
or "enable_sequential_scan", or maybe "enable_scan_sequential"?
Why doesn't "enable_nestloop" contain the word "join"?  Etc etc.

(I do have to wonder if maybe this one should be enable_sort_incremental.)

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: suggest to rename enable_incrementalsort
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Default setting for enable_hashagg_disk