Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Дата
Msg-id CAAaqYe-zwORT_L-aXj6OwyEm2OBr2M0Hjxsg=A7_UwF_JVQ6pA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
> > 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.

I'd be happy to yank this in favor of my holistic solution to this
problem I posted recently on the mailing list [1].

Assuming we go that route, I'd propose we still yank the existing todo
comment about turning it into a GUC.

[1] https://www.postgresql.org/message-id/flat/CAAaqYe8yKSvzbyu8w-dThRs9aTFMwrFxn_BkTYeXgjqe3CbNjg%40mail.gmail.com


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Speeding up INSERTs and UPDATEs to partitioned tables
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc