Re: explain plans with information about (modified) gucs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: explain plans with information about (modified) gucs
Date
Msg-id 24065.1545085015@sss.pgh.pa.us
Whole thread Raw
In response to Re: explain plans with information about (modified) gucs  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: explain plans with information about (modified) gucs
List pgsql-hackers
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.

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.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: explain plans with information about (modified) gucs
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions