Re: explain plans with information about (modified) gucs

On 12/18/18 12:43 AM, Andres Freund wrote:
> Hi,
> 
> On 2018-12-18 00:38:16 +0100, Tomas Vondra wrote:
>> On 12/17/18 11:16 PM, Tom Lane wrote:
>>> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>>>> Yeah, I've been thinking about that too. Currently it gets filtered out
>>>> because it's in the CLIENT_CONN_STATEMENT group, but the code only
>>>> includes QUERY_TUNING_*.
>>>> But we don't want to include everything from CLIENT_CONN_STATEMENT,
>>>> because that would include various kinds of timeouts, vacuuming
>>>> parameters, etc.
>>>> And the same issue applies to work_mem, which is in RESOURCES_MEM. And
>>>> of course, there's a lot of unrelated stuff in RESOURCES_MEM.
>>>> So I guess we'll need to enable QUERY_TUNING_* and then selectively a
>>>> couple of individual options from other groups.
>>>
>>> This is putting way too much policy into the mechanism, if you ask me.
>>>
>>
>> Doesn't that depend on how it'd be implemented? I have not envisioned to
>> make these decisions in explain.c, but rather to keep them in guc.c
>> somehow. Say in a function like this:
>>
>>     bool guc_affects_query_planning(config_generic *conf);
>>
>> which would be a fairly simple check outlined before (QUERY_TUNING_*
>> plus a couple of individual GUCs). Other use cases might provide similar
>> filters.
> 
> If we were to do that, I'd suggest implementing a GUC_* flag specified
> in the definition of the GUC, rather than a separate function containing
> all the knowledge (but such a function could obviously still be used to
> return such a fact).
> 

Seems reasonable.

> 
>> An alternative would be to somehow track this in the GUC definitions
>> directly (similarly to how we track the group), but that seems rather
>> inflexible and I'm not sure how would that handle ad-hoc use cases.
> 
> Not sure what problem you see here?
> 

My main concern with that was how many flags could we need, if we use
this as the way to implement this and similar use cases. There are 32
bits available, and 24 of them are already used for GUC_* flags. So if
we use this as an "official" way to support similar use cases, we could
run out of space pretty fast.

The callback would also allow ad hoc filtering, which is not very
practical from extensions (e.g. you can't define a new flag, because it
might conflict with something defined in another extension).

But I think that's nonsense - so far we have not seen any such use case,
so it's pretty pointless to design for it. If that changes and some new
use case is proposed in the future, we can rethink this based on it.

I'll go with a new flag, marking all GUCs related to query planning, and
post a new patch soon.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services