Subject: Re: explain plans with information about (modified) gucs
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: legrand legrand <legrand_legrand@hotmail.com>,
 pgsql-hackers@postgresql.org
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>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <2c09fe19-e4a0-ea66-5a7f-e69d46420e28@2ndquadrant.com>
Date: Tue, 18 Dec 2018 00:38:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <24065.1545085015@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


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