Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Дата
Msg-id 32262.1542322184@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Paul Ramsey <pramsey@cleverelephant.ca>)
Ответы Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (James Coleman <jtc331@gmail.com>)
Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Paul Ramsey <pramsey@cleverelephant.ca> writes:
> On Fri, Nov 9, 2018 at 1:32 PM James Coleman <jtc331@gmail.com> wrote:
>> Create new guc array_optimization_size_limit and use it to replace
>> MAX_SAOP_ARRAY_SIZE in predtest.c.

> My main comment is that the description of the purpose of the GUC doesn't
> help me understand when or why I might want to alter it from the default
> value. If nobody is going to alter it, because nobody understands it, it
> might as well remain a compile-time constant.

Yeah, that's sort of my reaction as well.  I also feel like this is a
mighty special case to expose as a separate GUC.  There are other magic
effort-limiting constants elsewhere in the planner --- we just added a
new one in e3f005d97, for instance --- and I can't get very excited about
exposing and trying to document them individually.  We also have a lot
of existing exposed knobs like join_collapse_limit and the various geqo
parameters, which basically nobody knows how to use, a precedent that
isn't encouraging for adding more.

There have been occasional discussions of inventing a master "planner
effort" control knob, with values say 1..10 [1], and allowing that one
thing to control all these decisions, as well as other things we might do
in the future that would cause increased planning time that might or might
not get paid back.  I'd rather see somebody put effort into designing a
coherent feature like that than figure out how to document finer-grained
knobs.

            regards, tom lane

[1] ... but my inner Spinal Tap fan wants it to go to 11.


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg11.1 jit segv
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: pg11.1 jit segv