I think that would remain similar to current behavior. Changing both system and session options today, changes defaults for both. But session level option takes precedence for that session.
select name,type,status,num_val from sys.options where name like '%max_query_memory_per_node%'; *+-------------------------------------------+----------+----------+--------------+* *| ** name ** | ** type ** | ** status ** | ** num_val ** |* *+-------------------------------------------+----------+----------+--------------+* *| *planner.memory.max_query_memory_per_node * | *SYSTEM * | *CHANGED * | * 21474836485 * |* *| *planner.memory.max_query_memory_per_node * | *SESSION * | *CHANGED * | * 21474836480 * |* *+-------------------------------------------+----------+----------+--------------+* 2 rows selected (0.313 seconds) So in the scenario you mentioned, I think "ALTER SYSTEM RESET A", should reset A only at the SYSTEM level but leave it changed at the SESSION level. -Abhishek On Thu, Sep 17, 2015 at 2:42 PM, Abdel Hakim Deneche <[email protected]> wrote: > I am looking at the corresponding pull request: > > https://github.com/apache/drill/pull/159 > > and I have a question I can't seem to find an answer in this discussion: > > Let's say a user changes an option A both at the SESSION and SYSTEM level. > What happens when the users issues "ALTER SYSTEM RESET A", does it reset A > only at the SYSTEM level but leave it changed at the SESSION level, or do > we want it to reset both SESSION and SYSTEM levels of A ? > > > > On Mon, Aug 10, 2015 at 3:24 PM, Abhishek Girish <[email protected]> wrote: > > > A session level *set* operation, by definition, should override the > > corresponding system level option for the duration of the session. > > > > Going by that, I think, a *reset* operation should default it back to the > > value held by the system level option. If a user (say an admin) has > updated > > the corresponding system option, the reverted value would be a custom, > > non-Drill-default value. And if not, the reverted value would be the > > Drill-default value. This would make it simpler to manage. > > > > > > On Mon, Aug 10, 2015 at 2:51 PM, Jason Altekruse < > [email protected] > > > > > wrote: > > > > > I don't know if I missed something, but the Postgres docs seem to > > indicate > > > that there is no equivalent to the concept of a SYSTEM option that > exists > > > in Drill, which can be set with a query. Options can be set at server > > > startup, either in a configuration file or with a command line > parameter > > > [2]. Once the server is running, it appears that the closest to our > ALTER > > > SYSTEM statement would be the feature to set options at a user or > > database > > > level [2]. > > > > > > Here is an excerpt from the docs on the DEFAULT option value: [1] - > > DEFAULT > > > can be written to specify resetting the parameter to its default value > > > (that is, whatever value it would have had if no SET had been executed > in > > > the current session). > > > > > > We should probably just try it out to confirm, but this statement leads > > me > > > to believe that the option will return to the value set in the startup > > > config file/parameter or what was set at the user/database level, not > the > > > system default. This is in agreement with my intuition on the issue, > the > > > whole idea behind nesting these configurations, from Drill default to > > > System and then to Session would seem to be trying to provide users > with > > > the safest environment possible. > > > > > > Setting something at the system level should only be done if the > > > administrator is certain that the non-standard option is a helpful > > > modification for the majority of their users. Thus users can choose to > > > override it, but their escape hatch should bring them back to the > option > > > values given by their administrator, not Drill defaults. > > > > > > [1] http://www.postgresql.org/docs/9.2/static/sql-set.html > > > [2] http://www.postgresql.org/docs/9.2/static/config-setting.html > > > > > > On Mon, Aug 10, 2015 at 2:25 PM, Sudheesh Katkam <[email protected] > > > > > wrote: > > > > > > > Correction: currently any user can SET or RESET an option for session > > and > > > > system. > > > > > > > > > On Aug 10, 2015, at 2:20 PM, Sudheesh Katkam <[email protected] > > > > > > wrote: > > > > > > > > > > Hey y‘all, > > > > > > > > > > Re DRILL-1065 <https://issues.apache.org/jira/browse/DRILL-1065>, > at > > > > system level (ALTER system RESET …), resetting an option would mean > > > > changing the value to the default provided by Drill. But, at session > > > level > > > > (ALTER session RESET …), would resetting an option mean: > > > > > (a) changing the value to the default provided by Drill? or, > > > > > (b) changing the value to the system value, that an admin could’ve > > > > changed? > > > > > > > > > > (b) would not allow non-admin users to know what the default is > > > > (easily). However, for a given option, (a) would allow a non-admin > user > > > to > > > > know what the default is (by resetting) and what the system setting > is > > > > (from sys.options). Opinions? > > > > > > > > > > Thank you, > > > > > Sudheesh > > > > > > > > > > > > > > > > > -- > > Abdelhakim Deneche > > Software Engineer > > <http://www.mapr.com/> > > > Now Available - Free Hadoop On-Demand Training > < > http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available > > >
