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).
> 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?
Greetings,
Andres Freund
