thanks for the info, ruilong. just realized that an attachment to the original email was not included. i've created a JIRA for outcomes of this discussion and included the spreadsheet there: https://issues.apache.org/jira/browse/HAWQ-1290.
-lisa On Fri, Jan 20, 2017 at 6:59 AM, Ruilong Huo <r...@pivotal.io> wrote: > Here is some general description of server configuration. Though some of > hawq guc is not following that. > > DEFUNCT GUC: should not be in doc; should not show in hawq config > > DEPRECATED GUC: should be in doc and mention that they are deprecated; > should show in hawq config > > DEVELOPER GUC: should not in doc; should not show in hawq config. More > details can be found in > https://www.postgresql.org/docs/9.5/static/runtime-config-developer.html > > PRESET GUC: should be in doc as read only; should show in hawq config. More > details can be found in > https://www.postgresql.org/docs/9.5/static/runtime-config-preset.html > > > Best regards, > Ruilong Huo > > On Fri, Jan 20, 2017 at 1:28 AM, Lisa Owen <lo...@pivotal.io> wrote: > > > hi hawq developers, > > > > i have been looking at src/backend/utils/misc/guc.c to try to get a > better > > understanding of hawq server configuration parameters (GUCs) and how they > > are exposed to end users and developers. i have initially focused on > GUCs > > with config groups labeled "DEVELOPER_OPTIONS", "DEFUNCT_OPTIONS", > > "DEPRECATED_OPTIONS", and "PRESET_OPTIONS". > > > > i have some general questions regarding these GUC config groups: > > 1. which GUCs and their values should be displayed/changeable via > "hawq > > config" command? > > 2. which of the GUCs are updatable, which are read-only? > > 3. which of the GUCs should be documented to the end user, and if/how > > to "flag them"? > > > > DEVELOPER_OPTIONS - it appears we expose some developer GUCs to the > > end-user. what does it mean for a GUC to be a developer option? (when) > > should developer options be displayed in "hawq config -l" output? (when) > > should developer GUCs be discussed in the docs? it seems we are somewhat > > inconsistent in these areas. many, but not all, of the GUCS labeled as > > "DEVELOPER_OPTIONS" are also identified as "GUC_NO_SHOW_ALL", which > > generally excludes them from "hawq_config -l" output. the documentation > > currently describes a few of the developer GUCs. if we are describing > > developer GUCs in end-user documentation, should we be flagging them as > > such? > > > > DEFUNCT_OPTIONS - the GUCs labeled "DEFUNCT_OPTIONS" are pretty > > straightforward from an external perspective - none of them are currently > > documented, and none show up in "hawq config -l" output. > > > > DEPRECATED_OPTIONS - GUCs that are part of the "DEPRECATED_OPTIONS" > config > > group are functioning, but not recommended for use. some are documented, > > some are not. should we be explicitly identifying deprecated GUCs as > such > > in the documentation? should we even be documenting them at all? should > > the values of deprecated GUCs show up in "hawq config -l" output? > > > > PRESET_OPTIONS - some of the GUCS labeled with "PRESET_OPTIONS" are > > identified as read-only in the documentation. i used hawq config to > change > > one of them, "hawq config -c block_size -v 32768", and the operation > > apparently worked (i.e. no error returned). so, what does it mean for a > > GUC to be preset? read-only? are they all read-only? some appear to be > > recognized by "hawq config -c" command, while others are not. > > > > i've pulled together a spreadsheet identifying the "DEVELOPER_OPTIONS", > > "DEFUNCT_OPTIONS", "DEPRECATED_OPTIONS", and "PRESET_OPTIONS" GUCs and > > whether or not: > > - the GUC is documented in the current HAWQ docs > > - the GUC and associated value show up in "hawq config -l" output > > (when run by superuser) > > and other notes. > > > > thanks for any clarity you can provide on which of these GUCs we should > be > > exposing to the end user. > > > > > > -lisa > > > > > > >
