hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lisa Owen <lo...@pivotal.io>
Subject Re: HAWQ server configuration parameters (GUCs)
Date Fri, 20 Jan 2017 21:53:13 GMT
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 <rhuo@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 <lowen@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
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message