Resetting an option
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
Re: Resetting an option
Correction: currently any user can SET or RESET an option for session and system. > On Aug 10, 2015, at 2:20 PM, Sudheesh Katkam 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
Re: Resetting an option
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 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 > 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 > >
Re: Resetting an option
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 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 > 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 > > 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 > > > > >
Re: Resetting an option
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 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 > > 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 > > 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 > > > 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>
Re: Resetting an option
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 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 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 < > altekruseja...@gmail.com > > > > > 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 > > > > 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 > > > > > wrote: > > > > > > > > >
