FROM TABLE

FROM TABLE shows that a PARTITION SCAN operator is reading a database table. A second message gives the table name, and, if there is a correlation name, it is printed on the next line. Under the FROM TABLE message in the previous example output, sysobjects is the table name and s is the correlation name. The previous example also shows additional messages under the FROM TABLE message. These messages give more information about how the PARTITION SCAN operator is directing the access layer of Adaptive Server to get the rows from the table being scanned.

The messages below indicate whether the scan is a table scan or an index scan:

Table Scan – the rows are fetched by reading the pages of the table.
Using Clustered Index – a clustered index is used to fetch the rows of the table.
Index: indexname – an index is used to fetch the table rows. If this message is not preceded by “using clustered index,” a nonclustered index is used. indexname is the name of the index that will be used.

These messages indicate the direction of a table or index scan. The scan direction depends on the ordering specified when the indexes were created and the order specified for columns in the order by clause or other useful orderings that can be exploited by operators further up in the query plan (for example, a sorted ordering for a merge-join strategy).

Backward scans can be used when the order by clause contains the ascending or descending qualifiers on index keys, exactly opposite of those in the create index clause.

```
Forward scan
```
```
Backward scan
```

The scan-direction messages are followed by positioning messages, which describe how access to a table or to the leaf level of an index takes place:

Positioning at start of table – a table scan that starts at the first row of the table and goes forward.
Positioning at end of table – a table scan that starts at the last row of the table and goes backward.
Positioning by key – the index is used to position the scan at the first qualifying row.
Positioning at index start/positioning at index end – these messages are similar to the corresponding messages for table scans, except that an index is being scanned instead of a table.

If the scan can be limited due to the nature of the query, the following messages describe how:

Scanning only the last page of the table – appears when the scan uses an index and is searching for the maximum value for scalar aggregation. If the index is on the column whose maximum is sought, and the index values are in ascending order, the maximum value will be on the last page.
Scanning only up to the first qualifying row – appears when the scan uses an index and is searching for the minimum value for scalar aggregation.

If the index key is sorted in descending order, the above messages for minimum and maximum aggregates are reversed.

In some cases, the index being scanned contains all of the columns of the table that are needed in the query. In such a case, this message is printed:

Index contains all needed columns. Base table will not be read.

If an index contains all the columns needed by the query, the optimizer may choose an Index Scan over a Table Scan even though there are no useful keys on the index columns. The amount of I/O required to read the index can be significantly less than that required to read the base table. Index scans that do not require base table pages to be read are called covered index scans.

If an index scan is using keys to position the scan, this message prints:

```
Keys are:
     Key <ASC/DESC>
```

This message shows the names of the columns used as keys (each key on its own output line) and shows the index ordering on that key: ASC for ascending and DESC for descending.

After the messages that describe the type of access being used by the scan operator, messages about the I/O sizes and buffer cache strategy are printed.