hawq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From yo...@apache.org
Subject [6/6] incubator-hawq-docs git commit: fix merge conflict with bestpractices/querying
Date Tue, 01 Nov 2016 23:23:07 GMT
fix merge conflict with bestpractices/querying


Project: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/commit/ab916122
Tree: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/tree/ab916122
Diff: http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/diff/ab916122

Branch: refs/heads/develop
Commit: ab916122987d3430606abeb3627700893d189e77
Parents: af50fc8 b0ca8aa
Author: Lisa Owen <lowen@pivotal.io>
Authored: Tue Nov 1 16:05:30 2016 -0700
Committer: Lisa Owen <lowen@pivotal.io>
Committed: Tue Nov 1 16:05:30 2016 -0700

----------------------------------------------------------------------
 admin/startstop.html.md.erb                            |  6 ++++++
 bestpractices/general_bestpractices.html.md.erb        |  2 ++
 bestpractices/querying_data_bestpractices.html.md.erb  | 10 ++++------
 reference/HAWQSiteConfig.html.md.erb                   |  2 ++
 reference/cli/admin_utilities/hawqactivate.html.md.erb |  2 ++
 reference/cli/admin_utilities/hawqstop.html.md.erb     |  1 +
 reference/guc/guc_category-list.html.md.erb            |  3 ++-
 reference/guc/guc_config.html.md.erb                   |  2 +-
 8 files changed, 20 insertions(+), 8 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-hawq-docs/blob/ab916122/bestpractices/querying_data_bestpractices.html.md.erb
----------------------------------------------------------------------
diff --cc bestpractices/querying_data_bestpractices.html.md.erb
index d805406,ef41fbf..e2fb983
--- a/bestpractices/querying_data_bestpractices.html.md.erb
+++ b/bestpractices/querying_data_bestpractices.html.md.erb
@@@ -16,14 -16,14 +16,12 @@@ If a query performs poorly, examine it
      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.
++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.
--
--


Mime
View raw message