Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: jtc331(at)gmail(dot)com, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Date: 2018-11-15 22:49:44
Message-ID: 32262.1542322184@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> On Fri, Nov 9, 2018 at 1:32 PM James Coleman <jtc331(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2018-11-15 23:03:35 Re: pg11.1 jit segv
Previous Message Andres Freund 2018-11-15 22:47:55 Re: pg11.1 jit segv