The macro variables SPDSEV1T and SPDSEV2T work in conjunction with the server
WHERE clause planner WHINIT.
The variables SPDSEV1T and SPDSEV2T are identical in purpose. You use them to specify
the row order of data returned in
WHERE processing. Which variable the server exercises depends on the evaluation strategy selected
by WHINIT. The SPDSEV1T evaluation strategy is indexed. The SPDSEV2T evaluation strategy
is non-indexed. Avoid using these options unless you completely understand the server
performance tradeoffs that depend on maintaining the order of data.
If compatibility with
Base SAS software is important, set both SPDSEV1T and SPDSEV2T to 0. When both evaluation
strategies are set to 0, the server returns data in row order whether the SPDSEV1T
or the SPDSEV2T strategy is selected.
You use a SAS procedure
to retrieve rows from a sorted table. Some SAS procedures can use
the sort order information to optimize how to receive and process
the rows. For example, you use PROC SQL to perform table joins on
a sorted table that uses WHERE predicates to filter table rows. PROC
SQL uses the sort order information to optimize the join strategy.
If you use the default values of SPDSEV1T and SPDSEV2T in these instances,
the SAS procedure receives the table rows in sorted order.
If the SAS procedure
that you submit does not use
the sorted order, the default values of SPDSEV1T and SPDSEV2T will
restrict the use of parallel WHERE clauses, which can negatively impact
performance. For example, PROC PRINT and most SAS DATA step code
does not take advantage of sorted tables. If you know that the SAS
procedure that you are submitting does not take advantage of a sorted
table, you can change the setting for SPDSEV1T or SPDSEV2T to 2. This
change allows parallel WHERE evaluations that can improve performance.
However, this should be done with care: A parallel WHERE evaluation
does not guarantee that rows are returned to SAS in sorted order,
and this can cause incorrect results for a SAS procedure that uses
that information.
Note: The SPDSEV1T and SPDSEV2T
usage that is discussed here does not apply to SQL statements that
are executed via the server SQL explicit pass-through facility.