Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.0 » SQL Anywhere Server - SQL Usage » Query Optimizer » Query optimization and execution » Reading execution plans » Reading graphical plans


Node Statistics field descriptions

Below are descriptions of the fields displayed in the Node Statistics section of a graphical plan.

Field Description


The total number of cache read requests by this operator which were satisfied by the buffer pool, and hence did not require a disk read operation for that page.


Total number of attempts made by this operator to read a page of the database file, typically for table and/or index pages.


The CPU time incurred by the processing algorithm represented by this node.


The cumulative number of pages that have been read from disk as a result of this node's processing.


The cumulative elapsed time required to perform disk reads for database pages required by this node for processing.


The commutative number of pages that have been written to disk as a result of this node's processing.


The cumulative elapsed time required to perform disk writes for database pages as required by this node's processing algorithm.


The FirstRowRunTime value is the actual elapsed time required to produce the first row of the intermediate result of this node.


The number of times the node was called to compute a result, and return that result to the parent node. Most nodes are called only once. However, if the parent of a scan node is a nested loop join, then the node might be executed multiple times, and could possibly return a different set of rows after each invocation.


The RunTime spent computing the result within this particular node, expressed as a percentage of the total RunTime for the statement.


The estimated amount of query memory that is expected to be used for this particular operator. If the actual amount of query memory used, which is reported as the Actual statistic, differs significantly then it may indicate a potential problem with result set size estimation by the query optimizer. A probable cause of this estimation error is inaccurate or missing predicate selectivity estimates.


The number of rows returned to the parent node as a result of processing the request. RowsReturned is often, but not necessarily, identical to the number of rows in the (possibly derived) object represented by that node. Consider a leaf node that represents a base table scan. It is possible for the RowsReturned value to be smaller or larger than the number of rows in the table. RowsReturned are smaller if the parent node fails to request all of the table's rows in computing the final result. RowsReturned may be greater in a case such as a GROUP BY GROUPING SETS query, where the parent Group By Hash Grouping Sets node requires multiple passes over the input to compute the different groups.

A significant difference between the estimated rows returned and the actual number returned could indicate that the optimizer might be operating with poor selectivity information.


This value is a measure of wall clock time, including waits for input/output, row locks, table locks, internal server concurrency control mechanisms, and actual runtime processing. The interpretation of RunTime depends on the statistics section in which it appears. In Node Statistics, RunTime is the cumulative time the node's corresponding operator spent during execution for this node alone. Both estimated and actual values for this statistic appear in the Node Statistics section.

If a node's RunTime is greater than expected for a table scan or index scan, then further analysis may help pinpoint the problem. The query may be contending for shared resources and may block as a result; you can monitor blocked connections using the sa_locks() system procedure. As another example, the database page layout on the disk may be suboptimal, or a table may suffer from internal page fragmentation. You may improve performance by executing the REORGANIZE TABLE statement. You can use the sa_table_fragmentation() and the sa_index_density() system procedures to determine whether the table or index are fragmented.