From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, legrand legrand <legrand_legrand(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: explain plans with information about (modified) gucs |
Date: | 2018-12-17 23:43:53 |
Message-ID: | 20181217234353.fde7vityxvoullil@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-12-17 23:44:02 | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Previous Message | Andres Freund | 2018-12-17 23:41:23 | Re: Copypasta in the PostgreSQL source |