diff --git a/gpdb-doc/dita/admin_guide/query/topics/query-profiling.xml b/gpdb-doc/dita/admin_guide/query/topics/query-profiling.xml index 0cb50a8c78b79678bcd8ff35563b277d6850f371..24dc1c226b4e52334ffc5f3e928f0ac35d7fe6a2 100644 --- a/gpdb-doc/dita/admin_guide/query/topics/query-profiling.xml +++ b/gpdb-doc/dita/admin_guide/query/topics/query-profiling.xml @@ -59,7 +59,16 @@ sequential disk page read. The first estimate is the start-up cost of getting the first row and the second is the total cost of cost of getting all rows. The total cost assumes all rows will be retrieved, which is not always true; for example, if the query uses - LIMIT, not all rows are retrieved. + LIMIT, not all rows are retrieved.The cost values generated by + the Pivotal Query Optimizer and the Postgres Planner are not directly comparable. The + two optimizers use different cost models, as well as different algorithms, to determine + the cost of an execution plan. Nothing can or should be inferred by comparing cost + values between the two optimizers.

In addition, the cost generated for any given + optimizer is valid only for comparing plan alternatives for a given single query and + set of statistics. Different queries can generate plans with different costs, even + when keeping the optimizer a constant.

To summarize, the cost is essentially an + internal number used by a given optimizer, and nothing should be inferred by examining + only the cost value displayed in the EXPLAIN plans.

  • rows —The total number of rows output by this plan node. This number is usually less than the number of rows processed or scanned by the plan node, reflecting the estimated selectivity of any WHERE clause conditions.