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.von...@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
