hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruilong Huo <r...@pivotal.io>
Subject Re: HAWQ server configuration parameters (GUCs)
Date Fri, 20 Jan 2017 14:59:44 GMT
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