From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pramsey(at)cleverelephant(dot)ca, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Convert MAX_SAOP_ARRAY_SIZE to new guc |
Date: | 2018-11-16 14:00:27 |
Message-ID: | CAAaqYe-zwORT_L-aXj6OwyEm2OBr2M0Hjxsg=A7_UwF_JVQ6pA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-11-16 14:27:43 | Re: Convert MAX_SAOP_ARRAY_SIZE to new guc |
Previous Message | Alvaro Herrera | 2018-11-16 13:38:58 | Re: Speeding up INSERTs and UPDATEs to partitioned tables |