From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: legrand legrand <legrand_legrand@hotmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: explain plans with information about (modified) gucs
Date: Tue, 18 Dec 2018 00:38:16 +0100
Message-ID: <2c09fe19-e4a0-ea66-5a7f-e69d46420e28@2ndquadrant.com> (raw)
In-Reply-To: <24065.1545085015@sss.pgh.pa.us>
References: <e1791b4c-df9c-be02-edc5-7c8874944be0@2ndquadrant.com>
<10561.1544800904@sss.pgh.pa.us>
<c1282df1-43a8-0854-dfee-790d7dd9c93a@2ndquadrant.com>
<631ae5c8-5581-6c5e-382c-2dcdb2e5c956@2ndquadrant.com>
<1545083780942-0.post@n3.nabble.com>
<1edcee55-ea96-d123-199d-4c5f1fc5003b@2ndquadrant.com>
<24065.1545085015@sss.pgh.pa.us>
On 12/17/18 11:16 PM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 12/17/18 10:56 PM, legrand legrand wrote:
>>> what would you think about adding
>>> search_path
>>> to that list ?
>
>> 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.
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.
> At least for the auto_explain use case, it'd make far more sense for
> the user to be able to specify which GUCs he wants the query space
> to be divided according to. While it's possible to imagine giving
> auto_explain a control setting that's a list of GUC names, I'm not
> sure how we adapt the idea for other use-cases. But the direction
> you're headed here will mostly ensure that nobody is happy.
>
I certainly don't want to base this on explicitly listing "interesting"
GUCs anywhere. That would make it pretty useless for the use case I care
about, i.e. using auto_explain to investigate slow plans, when I don't
really know what GUC the application might have changed (certainly not
in advance).
I can't really say how to adopt this to other use cases, considering
there are none proposed (and I can't think of any either).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, tgl@sss.pgh.pa.us, legrand_legrand@hotmail.com
Subject: Re: explain plans with information about (modified) gucs
In-Reply-To: <2c09fe19-e4a0-ea66-5a7f-e69d46420e28@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox