Skip to content
Permalink
Browse files
fix merge conflict with bestpractices/querying
  • Loading branch information
lisakowen committed Nov 1, 2016
2 parents af50fc8 + b0ca8aa commit ab916122987d3430606abeb3627700893d189e77
Show file tree
Hide file tree
Showing 8 changed files with 20 additions and 8 deletions.
@@ -124,6 +124,12 @@ For best results in using `hawq start` and `hawq stop` to manage your HAWQ syste
$ hawq stop master -M fast
$ hawq stop master -M immediate
```
- If you want to reload server parameter settings on a HAWQ database where there are active connections, use the command:


```shell
$ hawq stop master -u -M fast
```

- When stopping a segment or all segments, you can use the default mode of smart mode. Using fast or immediate mode on segments will have no effect since segments are stateless.

@@ -9,6 +9,8 @@ When using HAWQ, adhere to the following guidelines for best results:
- **Use a consistent `hawq-site.xml` file to configure your entire cluster**:

Configuration guc/parameters are located in `$GPHOME/etc/hawq-site.xml`. This configuration file resides on all HAWQ instances and can be modified by using the `hawq config` utility. You can use the same configuration file cluster-wide across both master and segments.

If you install and manage HAWQ using Ambari, do not use `hawq config` to set or change HAWQ configuration properties. Use the Ambari interface for all configuration changes. Configuration changes to `hawq-site.xml` made outside the Ambari interface will be overwritten when you restart or reconfigure HAWQ using Ambari.

**Note:** While `postgresql.conf` still exists in HAWQ, any parameters defined in `hawq-site.xml` will overwrite configurations in `postgresql.conf`. For this reason, we recommend that you only use `hawq-site.xml` to configure your HAWQ cluster.

@@ -16,14 +16,12 @@ If a query performs poorly, examine its query plan and ask the following questio
If the plan is not choosing the optimal join order, set `join_collapse_limit=1` and use explicit `JOIN` syntax in your SQL statement to force the legacy query optimizer (planner) to the specified join order. You can also collect more statistics on the relevant join columns.

- **Does the optimizer selectively scan partitioned tables?** If you use table partitioning, is the optimizer selectively scanning only the child tables required to satisfy the query predicates? Scans of the parent tables should return 0 rows since the parent tables do not contain any data. See [Verifying Your Partition Strategy](../ddl/ddl-partition.html#topic74) for an example of a query plan that shows a selective partition scan.
- **Does the optimizer choose hash aggregate and hash join operations where applicable?** Hash operations are typically much faster than other types of joins or aggregations. Row comparison and sorting is done in memory rather than reading/writing from disk. To enable the query optimizer to choose hash operations, there must be sufficient memory available to hold the estimated number of rows. Try increasing work memory to improve performance for a query. If possible, run an `EXPLAIN ANALYZE` for the query to show which plan operations spilled to disk, how much work memory they used, and how much memory was required to avoid spilling to disk. For example:
- **Does the optimizer choose hash aggregate and hash join operations where applicable?** Hash operations are typically much faster than other types of joins or aggregations. Row comparison and sorting is done in memory rather than reading/writing from disk. To enable the query optimizer to choose hash operations, there must be sufficient memory available to hold the estimated number of rows. Run an `EXPLAIN ANALYZE` for the query to show which plan operations spilled to disk, how much work memory they used, and how much memory was required to avoid spilling to disk. For example:

`Work_mem used: 23430K bytes avg, 23430K bytes max (seg0). Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen workfile I/O affecting 2 workers.`
`Work_mem used: 23430K bytes avg, 23430K bytes max (seg0). Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen workfile I/O affecting 2 workers.`

The "bytes wanted" (Work_mem) message from `EXPLAIN ANALYZE` is based on the amount of data written to work files and is not exact.

**Note**
The *work\_mem* property is not configurable. Use resource queues to manage memory use. For more information on resource queues, see [Configuring Resource Management](../resourcemgmt/ConfigureResourceManagement.html) and [Working with Hierarchical Resource Queues](../resourcemgmt/ResourceQueues.html).


The "bytes wanted" message from `EXPLAIN ANALYZE` is based on the amount of data written to work files and is not exact. The minimum `work_mem` needed can differ from the suggested value.


@@ -8,6 +8,8 @@ Configuration guc/parameters are located in `$GPHOME/etc/hawq-site.xml`. This co

**Note:** While `postgresql.conf` still exists in HAWQ, any parameters defined in `hawq-site.xml` will overwrite configurations in `postgresql.conf`. For this reason, we recommend that you only use `hawq-site.xml` to configure your HAWQ cluster.

**Note:** If you install and manage HAWQ using Ambari, be aware that any property changes to `hawq-site.xml` made using the command line could be overwritten by Ambari. For Ambari-managed HAWQ clusters, always use the Ambari administration interface to set or change HAWQ configuration properties.

- **[About Server Configuration Parameters](../reference/guc/guc_config.html)**

- **[Configuration Parameter Categories](../reference/guc/guc_category-list.html)**
@@ -4,6 +4,8 @@ title: hawq activate

Activates a standby master host and makes it the active master for the HAWQ system.

**Note:** If HAWQ was installed using Ambari, do not use `hawq activate` to activate a standby master host. The system catalogs could become unsynchronized if you mix Ambari and command line functions. For Ambari-managed HAWQ clusters, always use the Ambari administration interface to activate a standby master. For more information, see [Manging HAWQ Using Ambari](../../../admin/ambari-admin.html#topic1).

## <a id="topic1__section2"></a>Synopsis

``` pre
@@ -23,6 +23,7 @@ The `hawq stop` utility is used to stop the database servers that comprise a HAW
By default, you are not allowed to shut down HAWQ if there are any client connections to the database. Use the `-M fast` option to roll back all in progress transactions and terminate any connections before shutting down. If there are any transactions in progress, the default behavior is to wait for them to commit before shutting down.

With the `-u` option, the utility uploads changes made to the master `pg_hba.conf` file or to *runtime* configuration parameters in the master `hawq-site.xml` file without interruption of service. Note that any active sessions will not pick up the changes until they reconnect to the database.
If the HAWQ cluster has active connections, use the command `hawq stop cluster -u -M fast` to ensure that changes to the parameters are reloaded.

## Objects

@@ -4,7 +4,6 @@ title: Configuration Parameter Categories

Configuration parameters affect categories of server behaviors, such as resource consumption, query tuning, and authentication. The following sections describe HAWQ configuration parameter categories.


## <a id="topic_hfd_1tl_zp"></a>Append-Only Table Parameters

The following parameters configure the <span class="ph">append-only</span> tables feature of HAWQ.
@@ -349,6 +348,8 @@ When automatic statistics collection is enabled, you can run `ANALYZE` automatic
- [gp\_autostats\_mode](parameter_definitions.html#gp_autostats_mode)
- [log\_autostats](parameter_definitions.html#log_autostats)

**Note:** If you install and manage HAWQ using Ambari, be aware that property changes made using `hawq config` could be overwritten by Ambari. For Ambari-managed HAWQ clusters, always use the Ambari administration interface to set or change HAWQ configuration properties.

### <a id="topic37"></a>Runtime Statistics Collection Parameters

These parameters control the server statistics collection feature. When statistics collection is enabled, you can access the statistics data using the *pg\_stat* and *pg\_statio* family of system catalog views.
@@ -27,7 +27,7 @@ Many of the configuration parameters have limitations on who can change them and

By design, all HAWQ instances (including master and segments) host identical `hawq-site.xml` files. Using a common `hawq-site.xml` file across all HAWQ instances simplifies configuration of the cluster. Within each `hawq-site.xml` configuration file, some parameters are considered *segment* parameters, meaning that each segment instance looks to its own `hawq-site.xml` file to get the value of that parameter. By convention, these parameter names begin with the string `hawq_segment`. Others parameters are considered *master* parameters. By convention, these parameter names begin with the string `hawq_master`. Master parameters are only applied at the master instance and ignored by segments.

**Note:** If you use the `hawq config` utility to set configuration parameter values in `hawq-site.xml`, the utility synchronizes all configuration files. Any manual modifications that you made to individual `hawq-site.xml` files may be lost.
**Note:** If you use the `hawq config` utility to set configuration parameter values in `hawq-site.xml`, the utility synchronizes all configuration files. Any manual modifications that you made to individual `hawq-site.xml` files may be lost. Additionally, if you install and manage HAWQ using Ambari, do not use `hawq config` to configure HAWQ properties. If the cluster is restarted, Ambari will overwrite any changes made by `hawq config` For Ambari-managed HAWQ clusters, only use the Ambari administration interface to set or change HAWQ configuration properties.

This table describes the values in the Set Classifications column of the table in the description of a server configuration parameter.

0 comments on commit ab91612

Please sign in to comment.